Cached logons, WDigest and credential exposure settings

Credential Guard and LSA protection harden how Windows protects the secrets it holds. This guide is about how much it holds in the first place. A handful of settings decide whether a compromised machine gives up a cleartext password, a crackable hash of every recent domain user, or saved passwords for file shares and web apps. Most of them are free to change and break very little when you know what to look for.

Everything here applies to devices where Credential Guard cannot run as well: older hardware, VMs without nested virtualization, and domain controllers. It is the baseline under the Credential Protection series.

What Windows keeps, and where

Step 1: reduce cached logons

When a domain user signs in interactively, Windows stores a verifier so the same user can sign in later without a domain controller. The default keeps the last 10 users. On a shared workstation or a server, that is a list of every recent helpdesk technician and admin, each one a hash that can be cracked offline.

The setting is Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Interactive logon: Number of previous logons to cache (in case domain controller is not available). It writes CachedLogonsCount (a REG_SZ, not a DWORD) under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon.

The Microsoft security baselines do not configure this setting; Microsoft's own guidance names 0 as the countermeasure and suggests 2 for end-user and mobile computers, and CIS benchmarks recommend 4 or fewer. Pick the lowest your users can live with, and test a laptop by disconnecting it from all networks and signing in.

Two related points:

• Members of Protected Users never leave a cached verifier, which is one more reason to put human admins in that group (see admin tiering and Protected Users).
• Lowering the value does not erase existing verifiers immediately. Entries are overwritten as new users sign in. On servers where admin verifiers already exist, a value of 0 stops new caching; plan to rotate the passwords of privileged accounts that were previously cached on low-trust machines.

Step 2: pin WDigest off

WDigest is an old HTTP/SASL authentication package that needed the user's cleartext password in memory. Since Windows 8.1 and Windows Server 2012 R2 it no longer stores plaintext by default, but the behaviour is still controlled by one registry value that an attacker with admin rights can flip:

Key:   HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest
Value: UseLogonCredential  (REG_DWORD) = 0

Once it is set to 1, every subsequent interactive logon places the cleartext password in LSASS memory for tools like Mimikatz to read. This is a well-known persistence step in intrusions: flip the value, lock the screen, wait for the user to unlock.

Set it explicitly to 0 rather than relying on the default. The Security Compliance Toolkit's SecGuide.admx exposes it as WDigest Authentication (disabling may require KB2871997) under Computer Configuration > Policies > Administrative Templates > MS Security Guide; set it to Disabled. The KB reference only matters for Windows 7 and Server 2008 R2. Microsoft dropped this setting from the Windows 11 24H2 security baseline because the policy was deprecated with that release, so on current builds you can also enforce the registry value directly with Group Policy Preferences or Intune, and keep monitoring it either way.

Credential Guard also blocks Digest from using saved credentials, but a policy-enforced 0 protects the machines where it is not running.

Step 3: clear credentials after logoff

After a user logs off, LSASS can keep their credentials in memory for a while if handles to the logon session remain open. Windows 8.1 and later clear them after 30 seconds. The value is:

Key:   HKLM\SYSTEM\CurrentControlSet\Control\Lsa
Value: TokenLeakDetectDelaySecs  (REG_DWORD) = 30

On current Windows this is the built-in behaviour, so setting it is mostly a guard against someone raising it. The Microsoft security baseline does not require it; set it where your hardening standard or audit asks for it and leave it at 30 seconds.

Note that this only affects logged-off sessions. A privileged account that stays signed in to a server over RDP remains in memory for as long as the session lives. Set RDP session time limits and log off disconnected sessions, as covered in RDP hardening.

Step 4: stop saving network passwords

Credential Manager stores passwords that users (or applications) choose to save: mapped drives with "Remember my credentials", RDP connections, Outlook, some line-of-business apps. They are protected by DPAPI with the user's key, which means any code running as the user can decrypt them.

Check what is saved on a device, for the current user:

cmdkey /list
vaultcmd /listcreds:"Windows Credentials" /all

The policy Network access: Do not allow storage of passwords and credentials for network authentication (Security Options) sets DisableDomainCreds = 1 under HKLM\SYSTEM\CurrentControlSet\Control\Lsa. With it enabled, Windows no longer stores domain credentials for network authentication in Credential Manager.

This one needs testing, which is why many baselines leave it for high-security tiers:

• Scheduled tasks configured to Run whether user is logged on or not with a stored password stop working. Convert them to run as SYSTEM, a gMSA or a service account managed elsewhere.
• Saved RDP and mapped drive credentials stop persisting. Users are prompted again, which is usually the intended outcome.

Enable it on servers and privileged access workstations first, where saved domain credentials are the most dangerous and scheduled tasks are easiest to inventory. For RDP specifically, also enable Do not allow passwords to be saved under Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client.

Step 5: apply it by script and check it

For a quick baseline on a single machine or through a remediation script:

$lsa = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"
[pscustomobject]@{
  CachedLogonsCount        = (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon").CachedLogonsCount
  UseLogonCredential       = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" -ErrorAction SilentlyContinue).UseLogonCredential
  TokenLeakDetectDelaySecs = (Get-ItemProperty $lsa).TokenLeakDetectDelaySecs
  DisableDomainCreds       = (Get-ItemProperty $lsa).DisableDomainCreds
  NoLMHash                 = (Get-ItemProperty $lsa).NoLMHash
}

Enforce the values through Group Policy or Intune rather than by script, so they are re-applied if something changes them. In Intune, the Security Options settings are in the settings catalog under Local Policies Security Options; for values without a native setting, a custom OMA-URI using an ingested ADMX or a remediation script works.

What breaks

• Offline logon on laptops if cached logons are set to 0.
• Scheduled tasks with stored passwords and saved credentials once DisableDomainCreds is enabled.
• Very old applications using HTTP Digest authentication with Windows single sign-on. These are rare; they will prompt for a password.

Verify it

1. Cached logons in use. Security event 4624 with Logon Type 11 (CachedInteractive) shows a user signed in from a cached verifier. On servers this should never appear once the value is 0.
2. WDigest tampering. Alert on writes to UseLogonCredential with Sysmon Event 13 or registry auditing (Security event 4657, which needs a SACL on the key). Any change to 1 is a high-confidence indicator of compromise.
3. Credential Manager content. Run the cmdkey /list check on a sample of servers and admin workstations after enabling DisableDomainCreds; saved domain entries should be gone once users re-authenticate.
4. Fleet report. Collect the output of the Step 5 script centrally and track devices outside your standard.

Checklist

• Cached logons: 0 on servers and kiosks, 1 to 2 on laptops
• Human admin accounts in Protected Users so they are never cached
• UseLogonCredential explicitly 0 by policy, changes alerted on
• TokenLeakDetectDelaySecs at 30 where your standard requires it
• DisableDomainCreds enabled on servers and PAWs, scheduled tasks converted
• RDP client not allowed to save passwords
• Event 4624 logon type 11 on servers reviewed

None of these settings is dramatic, but together they cut the amount of reusable material on every machine. Combined with WDigest monitoring and Credential Guard, they leave an attacker with far less to collect.