How to Disable WinRM Basic Authentication (WN10-CC-000330 and WN10-CC-000345)

The WinRM Basic authentication finding (DISA STIG WN10-CC-000330 for the WinRM client, WN10-CC-000345 for the WinRM service) means no policy stops Windows from using Basic authentication, which sends the password base64-encoded instead of using Kerberos or NTLM. Fix it by setting both “Allow Basic authentication” policies to Disabled, which writes AllowBasic = 0 to the WinRM policy keys.

The change takes a few minutes. The part worth planning is finding the one script, playbook or tool that still logs on with Basic before you switch it off.

What the scanner is actually detecting

This is a configuration audit, not a missing patch. A Nessus compliance scan using a DISA Windows STIG audit file logs on to the host and reads two policy registry values. The STIG check text is strict: if the value does not exist, or is anything other than 0, the item fails. DISA rates both items CAT I (High).

Tenable also publishes CIS STIG benchmark audits that reuse the same IDs, for example item 1.170 WN10-CC-000330 in the CIS Microsoft Windows 10 STIG v1.0.0 audit. The fix is identical.

Real-world risk

Basic authentication sends the user name and password in a single header that is base64-encoded, not encrypted. Microsoft’s PowerShell remoting security guidance states plainly that Basic provides no encryption. Over HTTP (port 5985), WinRM normally protects traffic with message-level encryption negotiated by Kerberos or NTLM. Basic brings none, which is why Basic over HTTP goes together with allowing unencrypted traffic, a separate STIG item (WN10-CC-000335 on the client side).

Over HTTPS (port 5986), TLS protects the credential in transit, but the server still receives the reusable password. Kerberos and NTLM prove identity without handing the password to the target. Basic on the WinRM service also only works with local accounts, so where you find it you often find a shared local administrator password used across many hosts.

The client setting matters because it decides whether this machine will send a password with Basic when a script or an administrator asks for it, including to a mistyped or impersonated endpoint.

Keep the rating in perspective. Nothing is exposed unless something actually uses Basic, and Microsoft documents the WinRM service default as Basic = false. In most fleets this finding means “the policy is not set” rather than “passwords are crossing the wire”. It is still worth closing: the fix is cheap and it stops someone from turning Basic on later for convenience.

How to confirm it on the host

The audit reads the policy registry values, so check those first:

reg query "HKLMSOFTWAREPoliciesMicrosoftWindowsWinRMClient" /v AllowBasic
reg query "HKLMSOFTWAREPoliciesMicrosoftWindowsWinRMService" /v AllowBasic

• 0x0: passes.
• Unable to find the specified registry key or value: fails. The policy is not configured.
• 0x1: fails. A policy is actively allowing Basic, which usually means someone needed it. Find out who before you change it.

To see the effective WinRM configuration, including listeners:

winrm get winrm/config/client/auth
winrm get winrm/config/service/auth
winrm enumerate winrm/config/listener

These commands need the WinRM service to be running. On workstations it is often stopped, and winrm get then fails with error 0x80338012. The registry query works either way. To find which GPO sets the value, run gpresult /scope computer /h C:Tempgp.html and search the report for “Allow Basic authentication”.

Before changing anything, look for Basic in your own automation, for example:

Select-String -Path .scripts*.ps1 -Pattern '-Authentications+Basic'

Also check Ansible inventories for ansible_winrm_transport: basic.

How to fix it

Domain-joined hosts: Group Policy

1. Edit a GPO linked to the target computers.
2. Go to Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Client and set Allow Basic authentication to Disabled.
3. Go to … > Windows Remote Management (WinRM) > WinRM Service and set Allow Basic authentication to Disabled.
4. While you are there, set Allow unencrypted traffic to Disabled in both folders. Those are the companion STIG items.
5. Run gpupdate /force on a test machine, or wait for the normal refresh.

Choose Disabled, not Not Configured. Only Disabled writes the value 0 that the audit looks for. Group Policy values take precedence over the local WinRM configuration, so this is the setting that sticks. The same values apply to Windows Server, so add them to your Windows Server hardening checklist baseline rather than handling servers separately.

Standalone hosts or scripted rollout: registry

From an elevated prompt:

reg add "HKLMSOFTWAREPoliciesMicrosoftWindowsWinRMClient" /v AllowBasic /t REG_DWORD /d 0 /f
reg add "HKLMSOFTWAREPoliciesMicrosoftWindowsWinRMService" /v AllowBasic /t REG_DWORD /d 0 /f

On a domain-joined machine, a GPO that sets a different value will overwrite this at the next refresh, so fix the GPO instead.

Intune-managed devices

The RemoteManagement Policy CSP exposes both settings as ADMX-backed policies: ./Device/Vendor/MSFT/Policy/Config/RemoteManagement/AllowBasicAuthentication_Client and …/AllowBasicAuthentication_Service. Set both to disabled in the settings catalog (search for “Allow Basic authentication”) or through a custom profile. They map to the same registry values.

Optional: align the local WinRM configuration

On hosts where the WinRM service runs, you can also set the local values. In PowerShell, keep the single quotes; in cmd.exe, drop them:

winrm set winrm/config/client/auth '@{Basic="false"}'
winrm set winrm/config/service/auth '@{Basic="false"}'

This alone does not pass the audit, because the audit reads the policy key.

What to use instead of Basic

• Domain-joined client and server: Kerberos. Microsoft documents it as the default when the client is in a domain and you connect by name. Nothing to configure.
• Workgroup hosts or connections by IP address: Negotiate, which falls back to NTLM. Microsoft’s remoting guidance suggests an HTTPS listener (winrm quickconfig -transport:https) so NTLM connections also verify the server’s identity. If you are also restricting NTLM, read how to disable NTLM safely first so you do not remove both options at once.
• Non-interactive automation against local accounts: client certificate authentication over HTTPS. Certificates map only to local accounts, and both the client and service must allow Certificate.

How to verify the fix and rescan

Check many hosts at once. This uses PowerShell remoting with Kerberos, which also proves remoting still works:

Invoke-Command -ComputerName (Get-Content .hosts.txt) -ScriptBlock {
    [pscustomobject]@{
        Client  = (Get-ItemProperty 'HKLM:SOFTWAREPoliciesMicrosoftWindowsWinRMClient' -ErrorAction SilentlyContinue).AllowBasic
        Service = (Get-ItemProperty 'HKLM:SOFTWAREPoliciesMicrosoftWindowsWinRMService' -ErrorAction SilentlyContinue).AllowBasic
    }
} | Select-Object PSComputerName, Client, Service

Every row should show 0 in both columns. An empty value means the policy has not arrived yet. A request that explicitly asks for Basic should now be refused:

Invoke-Command -ComputerName srv01 -UseSSL -Authentication Basic -Credential (Get-Credential) -ScriptBlock { hostname }

Then rerun the STIG compliance scan and confirm both items show PASSED. No reboot is needed for the rescan, because the audit reads the registry values.

What can break and how to roll back

• Ansible with Basic transport. The Ansible WinRM documentation notes Basic works only with local accounts. Switch the playbooks to ntlm, kerberos, credssp or certificate before the policy lands.
• Legacy Exchange Online remote PowerShell. Old remote PowerShell sessions required client-side WinRM Basic. Microsoft states that REST API connections in version 3.2.0 and later of the Exchange Online PowerShell module do not need it, so update the module on admin workstations.
• Custom scripts and third-party tools that pass -Authentication Basic or are configured for Basic against local accounts.

To roll back one host, for example so its service accepts Basic again, set the value back:

reg add "HKLMSOFTWAREPoliciesMicrosoftWindowsWinRMService" /v AllowBasic /t REG_DWORD /d 1 /f

For a GPO rollout, do not undo the baseline for everyone. Create a separate GPO that sets the policy to Enabled, scope it with security filtering to the exception hosts, allow Basic only over an HTTPS listener, keep unencrypted traffic disabled, and record the exception.

Common false positive reasons

• Not configured, but not exposed. The service may already refuse Basic by default, yet the audit fails because the policy value is missing. This is a correct result by the STIG’s definition; setting the policy closes it.
• Not Configured instead of Disabled. The GPO exists but the setting was left at Not Configured, so no value is written.
• WinRM stopped or no listener. The check still applies, because it reads the registry rather than probing ports 5985 and 5986.
• Stale results. The scan ran before the host picked up the GPO, or the host was offline during the refresh.
• Registry access failed. If the credentialed scan could not read the registry, the item may report an error or fail. Check the scan’s authentication results before touching the host.

FAQ

Is WinRM Basic authentication enabled by default?

Microsoft documents the service default as false. For the client, Microsoft’s own pages disagree, so check winrm get winrm/config/client/auth on your build. The audit fails without the policy value either way.

Will disabling Basic break PowerShell remoting?

Not in a domain. Remoting uses Kerberos by default and NTLM for workgroup hosts or IP addresses. Only sessions that explicitly request Basic stop working.

Is Basic over HTTPS acceptable?

TLS protects the password in transit, but the server still receives it, and the STIG makes no HTTPS exception. If a system truly needs it, restrict it to HTTPS and document the exception.

Do I need to restart anything?

No reboot is required. Run gpupdate and rescan. If winrm get still shows the old value on a host where the service is running, restarting the WinRM service ends open remoting sessions, so do it outside working hours.

Tracking this finding across many hosts

STIG items like these tend to fail on every workstation and server at once, so the work is mostly tracking. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners, including Nessus results uploaded as .nessus exports (not synced automatically), and merges duplicates within each scanner, not across scanners. Its AI can draft host-specific remediation scripts, such as the registry change above, which run only after human approval through its agents on Windows endpoints, and the platform re-tests afterwards to confirm closure; per-finding retest is available for Nessus results.

Sources

• Tenable: WN10-CC-000330, WinRM client must not use Basic authentication (DISA Microsoft Windows 10 STIG v3r6)
• Tenable: WN10-CC-000345, WinRM service must not use Basic authentication (DISA Microsoft Windows 10 STIG v3r6)
• Microsoft Learn: RemoteManagement Policy CSP
• Microsoft Learn: Installation and configuration for Windows Remote Management
• Microsoft Learn: Security considerations for PowerShell Remoting using WinRM