Why Windows Credentialed Scans Fail and How to Fix It

A Windows credentialed scan that reports “authentication failure” almost never means the password is wrong. It means one hop in a four-part chain broke, and the scanner collapsed every possible cause into a single generic status line. Fixing it fast means knowing the chain well enough to test each link by hand before you re-run a scan and wait another hour for the same result. This is the diagnostic path: what the scanner actually does on the wire, which registry keys and firewall rules gate each step, how to read the real error code instead of the friendly message, and a checklist you can run against one host in under five minutes.

The four-hop chain a scanner actually walks

A credentialed Windows scan is not one authentication event. It is a sequence of at least four, and any scanner (Nessus, Qualys, Rapid7, OpenVAS, or a custom WinRM-based check) walks roughly the same path:

• SMB session setup on TCP 445 (or 139 with NetBIOS session service on 137/138). This establishes the security context the rest of the scan reuses.
• Access to an administrative share, almost always ADMIN$ or IPC$, which proves the account has local administrator rights on the target, not just valid credentials.
• RemoteRegistry queries for patch levels, installed software, and configuration values that are cheaper to read from the registry than to enumerate through WMI.
• WMI over DCOM/RPC (endpoint mapper on TCP 135, then a dynamic high port) for anything the registry does not expose directly: services, processes, installed hotfixes via Win32_QuickFixEngineering, and detailed OS metadata.

Each of these four steps has its own service dependency, its own firewall rule group, and its own way of denying access even when the credential itself is perfectly valid. A scan report that says “authentication failed” after step one succeeded is misleading; the credential worked, but step three or four did not. Platforms that pull results from several engines at once, such as SITEY through its scanner integrations layer, still depend on this same underlying chain succeeding on the Windows side before any finding from any engine can be treated as complete rather than partial.

Remote UAC and the LocalAccountTokenFilterPolicy decision

This is the single most common cause of “credentials are correct but access is denied,” and it only affects local accounts, not domain accounts.

Since Windows Vista, User Account Control filters the access token of a local (non-domain) account when it authenticates over the network to a non-domain-joined or workgroup machine, unless that account is the built-in Administrator (RID 500). The filtered token behaves like a standard user token for anything requiring elevation, which is exactly what a credentialed scan needs. The account can log on, but every privileged operation, including ADMIN$ access and most WMI classes, gets denied.

The control is a single DWORD:

HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemLocalAccountTokenFilterPolicy

Set it to 1 to disable the filtering and let a local admin account keep its full token remotely. Leave it at 0 (the default) and only RID 500 gets full remote admin rights; every other local admin account is silently downgraded. If your scan account is a domain account in the local Administrators group, this key does not apply to you; domain accounts are not subject to remote UAC filtering by default. If you are still seeing access-denied errors with a domain account, look at the next section instead.

A related setting that produces the same symptom from a different angle: Network access: Sharing and security model for local accounts. If this local security policy is set to “Guest only,” every network logon using a local account is mapped to the Guest account regardless of the credentials supplied. Confirm it is set to “Classic, local users authenticate as themselves” on any host you plan to scan with local credentials.

Services and firewall rules that must stay reachable

Hardened builds (CIS benchmarks, DISA STIGs, internal baselines) routinely disable exactly the surface a credentialed scan needs, because that surface is also what lateral movement tooling uses. Before assuming a credentials problem, confirm these are not the actual cause:

• Server service (LanmanServer) must be running for ADMIN$ and IPC$ to exist at all. Some hardening guides disable the default administrative shares outright by setting AutoShareServer / AutoShareWks to 0, which removes ADMIN$ on every reboot even if the service itself is running.
• RemoteRegistry defaults to Manual start on workstations and is frequently set to Disabled on hardened servers. A disabled RemoteRegistry service does not fail the whole scan, it fails only the registry-based checks, so you can end up with a scan that “succeeds” but silently under-reports patch and configuration findings.
• RPC endpoint mapper (TCP 135) plus the dynamic RPC port range (49152 to 65535 by default on current Windows) must be open inbound from the scanner. Restricting the dynamic range with netsh int ipv4 set dynamicportrange is common in segmented networks; if you do this, mirror the same range in the firewall rule rather than leaving the default rule pointing at the old range.
• Windows Firewall rule groups: “File and Printer Sharing,” “Windows Management Instrumentation (WMI),” and “Remote Administration” all need to be enabled for the scanner’s source profile (Domain, Private, or Public, matching however the target classifies the scanner’s subnet). It is common to see these enabled for Domain profile only, which silently blocks a scanner sitting on a management VLAN that the target treats as Public.
• Network access: Restrict clients allowed to make remote calls to SAM, hardened by default since Windows Server 2016 and Windows 10 1607, can block SAM-based enumeration even when SMB and WMI both work, producing partial results rather than an outright failure.

Decoding the authentication failure message into the real root cause

Scanner UIs compress Windows error codes into short phrases. The phrase is a hint, not a diagnosis. Match what you see against the underlying code and you save the guesswork:

One more code worth knowing even though it rarely surfaces in the scanner UI directly: Security event 4625 on the target logs a sub-status for every failed logon. Pulling that event from the target’s own event log during a test connection is more reliable than trusting the scanner’s paraphrase, especially when the scanner batches several failure types under one label.

Domain vs local scan accounts: lockout risk, logon type, and audit noise

A domain account scanning hundreds of hosts in parallel is efficient, but a single bad password entry (after a rotation the scan config missed) turns into hundreds of failed logons in seconds, which can trip the domain-wide account lockout threshold and lock the account everywhere at once, not just on the host you were testing. Two practical mitigations: pilot a credential change against a small host group before rolling it out fleet-wide, and consider a fine-grained password policy for the scan account with a higher lockout threshold than your general user policy, since it is a non-interactive account that should never appear in a normal bad-password pattern.

A local account avoids the lockout blast radius but multiplies management overhead: the same username and password must exist identically on every target, which usually means LAPS or an equivalent rotation tool, and it brings the LocalAccountTokenFilterPolicy question back into play.

Logon type matters for both audit noise and for policy scope. A credentialed scan authenticates as Logon Type 3 (Network), not Logon Type 2 (Interactive) or Type 10 (RemoteInteractive), so it should never require “Allow log on locally” or trip RDP-specific conditional access rules. If your scan account does need Type 2 for some legacy check, treat that as a red flag; a scan account should not need interactive rights on anything.

The other common trap is NTLM restriction. WMI and SMB reached by IP address authenticate over NTLM, not Kerberos, because Kerberos needs a service principal name tied to a hostname. If your domain enforces “Network security: Restrict NTLM: NTLM authentication in this domain” with an audit or deny setting, scans launched against bare IP addresses can fail even with perfect credentials, while the identical scan against the same host by hostname succeeds because it negotiates Kerberos instead. Check event ID 8004 on the domain controller for NTLM blocking before assuming the account itself is the problem.

Whichever account model you choose, keep a record of which credential authenticated against which host and when the last successful full check-in was. That mapping is what turns a stale “last seen three scans ago” host into an actionable exception item rather than something that quietly falls out of the asset inventory because nobody noticed the authentication gap.

A one-host verification checklist before you launch the full scan

Run this from the scanner host, or from a jump box with the same network path and account, against one representative target before committing to a full run:

1. Confirm SMB and RPC ports answer: Test-NetConnection -ComputerName target -Port 445 and Test-NetConnection -ComputerName target -Port 135.
2. Confirm the admin share is reachable with the exact scan credential: net use targetADMIN$ /user:DOMAINsvc-scan, entering the password when prompted. A path-not-found error here points at the firewall or the Server service, not the credential.
3. Check RemoteRegistry’s actual state on the target: sc.exe target query RemoteRegistry. If it reports STOPPED with a Disabled start type, decide now whether to enable it via policy or accept that patch-level checks will be incomplete on that host.
4. Confirm WMI answers with the scan credential: Get-CimInstance -ComputerName target -ClassName Win32_OperatingSystem -Credential (Get-Credential). A caption and version coming back means DCOM/RPC and the credential are both fine.
5. Confirm the account is actually a local admin on the target, not just a member of a group that used to grant it: net localgroup administrators run against the target, or query Win32_Group through the same WMI session.
6. If using a local account, check the token filtering key directly: reg query “HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem” /v LocalAccountTokenFilterPolicy on the target.
7. If scanning by IP, pull event ID 8004 from the relevant domain controller after the test connection to rule out NTLM restriction before blaming the credential.
8. Confirm the relevant firewall rule groups are enabled for the correct network profile: Get-NetFirewallRule -DisplayGroup “Windows Management Instrumentation (WMI)”,”File and Printer Sharing”,”Remote Administration” | Select DisplayName, Profile, Enabled.

Once this checklist passes clean on one representative host per build image or GPO baseline, the failure rate on the full run drops sharply, because most fleet-wide authentication failures trace back to one of these settings being wrong on an entire OU rather than being random per-host flakiness. Wiring this same checklist into a small scheduled pre-flight check, run a few minutes ahead of the real job through scan management, catches a broken GPO push before it burns an entire scan window on a target group that was never going to authenticate.

None of this is scanner-specific tuning; it is Windows remote administration plumbing that predates vulnerability management as a category. Platforms built to run this discovery step automatically, SITEY among them, still surface the same four-hop chain under the hood during the Discovery and Scanning phase, because there is no way around it: an unauthenticated host produces registry-derived and network-derived findings only, and treating that partial view as equivalent to a fully authenticated result is how real missing patches get missed. Whatever tool sits in front of the chain, the fix always lives in one of the six places above, not in retyping the password a third time.

About SITEY

SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.