Starting point: offline availability leaves a local verifier

Domain members should remain usable when no Domain Controller is reachable during sign-in. After successful online logons, Windows therefore stores local information for a limited number of domain users. If one of those users signs in later without DC connectivity, the device can validate the supplied password against the local verifier and open an offline session.

This is not a plaintext domain password and it is not a normal network credential that can simply be presented to another system. It is still security-relevant. Someone who gains complete control of a device and its protected system data can test password candidates against the local verifier without involving Active Directory. Account lockout and online detection do not constrain that offline process.

Credential Guard does not change this assessment. Cached domain verifiers are not reusable sign-in credentials of the kind isolated by Credential Guard. BitLocker, Secure Boot, physical protection and a defensible device configuration make access to local system data harder, but they do not replace a deliberate decision about how many users should be cached.

Without an explicit policy, Windows clients and member servers commonly retain information for as many as ten distinct domain users. The value represents user slots, not failed attempts, days or password versions. When another user authenticates online after all slots are occupied, the oldest entry is displaced. The entries do not have their own time-based expiry.

Availability matters just as much. A mobile device with no cache and no route to a Domain Controller cannot accept a domain sign-in. A VPN that starts only after user sign-in cannot help at that point. Conversely, an existing offline verifier may still match the last password known on that device even though the account was locked, disabled or had its password changed elsewhere. Until the device reaches a DC, it does not know the new state.

Cached domain logons are therefore neither universally bad nor a convenience switch that should remain at its default everywhere. They are a trade-off between local attack surface, offline productivity and recoverability.

Target state: give each device type only the offline reserve it needs

A defensible target state does not apply one value to the whole domain. It maps the policy to each device's operating model:

  1. Member servers authenticate online by design. Where DC, DNS and network connectivity are resilient, 0 is the appropriate starting point. An exception needs a concrete recovery case.
  2. Privileged access workstations and Tier 0 administration systems avoid offline domain sign-in. Their target is also 0, provided a separate, tested recovery path exists.
  3. Fixed office clients use 0 or a very small value. Site resilience, pre-logon VPN and the support model determine the choice.
  4. Mobile and genuinely offline clients keep a small reserve. 1 or 2 is often a practical pilot value. Two slots can, for example, prevent a maintenance logon from immediately evicting the device owner's only cached entry.
  5. Shared, kiosk, VDI and RDS systems are assessed separately. An always-connected or nonpersistent workload usually needs no local cache, while two slots may already be too few for a shared offline laptop.
  6. Domain Controllers are not secured through this setting. They hold the authoritative domain database and need their own Tier 0 logon and recovery architecture.
  7. Computer Group Policy manages the value by device class. A documented owner is accountable for the target, exceptions, pilot and review.
  8. Offline sign-in and recovery are tested in practice. Pre-logon networking, a Windows LAPS-managed local recovery account, BitLocker recovery and support procedures work before enforcement.

The objective is not the lowest theoretically possible number. It is the smallest value that still permits the device class to operate and recover safely in its real failure scenarios.

Implementation: design policy, connectivity and recovery together

1) Inventory the effective value and device populations

Start with the effective state on representative clients and member servers. The policy value is stored under Winlogon as a string. This query is read-only:

Set-StrictMode -Version Latest

$winlogonPath = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon'

$policyItem = Get-ItemProperty -LiteralPath $winlogonPath -ErrorAction Stop
$cachedLogonsCount = if ($policyItem.PSObject.Properties.Name -contains 'CachedLogonsCount') {
  [string]$policyItem.CachedLogonsCount
} else {
  'Not configured'
}

[pscustomobject]@{
  ComputerName      = [Environment]::MachineName
  CachedLogonsCount = $cachedLogonsCount
}

A missing registry value does not automatically mean 0. It initially shows only that the setting was not explicitly written there; the operating-system default may still apply. Correlate the result with Resultant Set of Policy, GPO links and the platform that actually manages the device. Registry Preferences, local security policy and security baselines can conflict with an apparently authoritative domain GPO.

Record at least the following for each device class:

  • current and intended number of slots,
  • normal number of users per device,
  • site, LAN, wireless and VPN behavior before sign-in,
  • reliance on user VPN or a device tunnel,
  • local recovery accounts and how they are managed,
  • BitLocker, Secure Boot and device-health state,
  • support and maintenance logons,
  • Windows Hello for Business, smart card or other sign-in methods,
  • longest realistic period without DC connectivity.

The configured slot count does not reveal which users are currently stored. Do not extract LSA secrets or registry hives to build an inventory. Policy state, device class, known sign-in workflows and event data are sufficient for this project.

2) Choose targets from real failure scenarios

For a member server, ask first why a domain user should be able to sign in when no Domain Controller is reachable. If the answer is merely “for emergencies,” the environment usually lacks a defensible recovery design. A local recovery account managed by Windows LAPS or out-of-band access is clearer than an unknown set of old domain verifiers.

On PAWs, offline availability is not automatically more important than reducing high-value local verifier material. A value of 0 is suitable only when the systems can reliably reach a DC before sign-in and an outage will not be bridged with an unsafe shared administrator account.

For fixed user devices, 0 can be appropriate when a site has redundant DC and DNS paths or a working pre-logon tunnel. Without that resilience, 1 or 2 may be the more honest transitional choice. Do not copy a value from a generic benchmark. Test it against site outages, laptop docks, wireless sign-in and the actual help-desk process.

Mobile devices routinely need offline sign-in. A value of 2 is a useful starting point, not a universal rule. Devices used by shifts, rotating staff or field support may require more slots or a different device model. A personally assigned laptop, by contrast, rarely needs ten cached domain identities.

Treat authentication methods separately. CachedLogonsCount controls cached domain account information used for offline sign-in. It does not remove local accounts, Windows Vault entries, browser passwords, service credentials or existing sessions. Windows Hello for Business also has its own key and trust model; test its online and offline behavior in the trust model you actually deploy.

3) Use separate computer GPOs instead of changing a global default

The setting is located at:

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)

Values from 0 through 50 are valid; 0 disables offline domain sign-in through this cache. The supported security-policy and GPO path does not require a restart. Microsoft's operational guidance treats direct registry changes differently, and they should not be the production method. Even so, validate the effective state after Group Policy processing with a full restart and a fresh online and offline sign-in sequence.

Create dedicated GPOs for clearly separated device populations, for example:

  • member servers and PAWs: target 0,
  • fixed standard clients: pilot 0, 1 or 2 according to site design,
  • mobile standard clients: pilot 2,
  • justified specialist devices: a documented separate value.

Do not change the Default Domain Policy for this purpose. Use stable OUs or controlled security filtering and make one setting authoritative on each device. A separate Registry Preference for CachedLogonsCount makes the result harder to reason about and should be removed once the security policy is authoritative.

4) Establish sign-in and recovery paths before rollout

A target of 0 requires DC connectivity before domain sign-in. Validate DNS, time, certificates, network access and authentication as one end-to-end path. Remote devices may require an Always On VPN device tunnel, a supported pre-logon VPN solution or another connection that does not depend on the user's desktop session.

A user VPN established after the desktop starts cannot enable a sign-in that already failed because caching was disabled. Likewise, a newly provisioned device cannot sign a user in offline until that user's domain identity has been successfully validated online at least once.

Design a separate local recovery path. A local administrator account managed through Windows LAPS is more appropriate for many clients and member servers than permanently caching privileged domain accounts. Its password remains protected, rotates after use and is monitored. The account is not a routine support identity and does not replace network recovery.

Rollback must work while the device is offline. A corrective GPO can help a locked-out device only after it reaches a Domain Controller again. Pilot devices therefore need a proven method for local access, network recovery or out-of-band management.

5) Test offline sign-in with a fixed matrix

Do not test only whether the primary user can still sign in after the change. A defensible matrix includes at least:

  1. known user sign-in with a reachable DC,
  2. repeated sign-in by that user without network connectivity,
  3. sign-in by a user with no existing cache entry,
  4. a maintenance logon followed by offline sign-in by the device owner,
  5. a password changed on another system followed by isolated tests with the old and new password,
  6. a locked or disabled test account without DC connectivity,
  7. first user sign-in on a newly provisioned device,
  8. pre-logon VPN when a gateway or Domain Controller is unavailable,
  9. local LAPS recovery and return to normal domain sign-in,
  10. Windows Hello, smart-card and password paths where deployed.

Run these tests in a lab or tightly controlled pilot. In particular, account disablement and password changes must not be improvised with production identities.

Security event 4624 with Logon Type 11 identifies a successful CachedInteractive sign-in. It is useful evidence of offline use, but not a complete real-time signal: a disconnected device can forward its logs only after connectivity returns. LsaSrv event 45058 can additionally report that an older entry was displaced when a slot was populated, but it should not be treated as a user inventory.

Baseline which device classes actually generate Type 11. CachedInteractive on a mobile laptop may be expected; on a Tier 0 administration system or member server it deserves investigation. Alert according to device class, account and frequency rather than on every individual event.

6) Roll out in rings and control drift permanently

Start with IT and security devices that represent the intended design but can be recovered locally and quickly. The pilot must include a real remote, site or VPN outage scenario. Only then expand to representative business teams, branch sites and mobile populations.

Do not change the VPN client, sign-in method, device certificates and cache policy in the same first change. If something fails, neither the root cause nor the rollback path will be clear. Keep the last-known-good GPO backed up and document how an offline device regains connectivity.

After rollout, monitor:

  • effective CachedLogonsCount against the device-class target,
  • Type-11 sign-ins on servers, PAWs and fixed clients,
  • devices without a current GPO or MDM check-in,
  • exceptions without an owner or expiry date,
  • help-desk incidents after password changes or long offline periods,
  • changes to VPN, provisioning and recovery procedures.

The policy belongs to the device lifecycle. New laptop classes, shared-device use, site closures or a VPN product change can alter the correct slot count. An annual review is sufficient only when such architecture changes feed into the security change process.

Advantages

  • Fewer local password verifiers: A small slot count reduces the number of domain identities whose passwords could be tested offline on a lost or fully compromised device.
  • No offline domain logon on always-on systems: With 0, servers, PAWs and fixed clients do not accept a cached domain sign-in when the DC path is unavailable.
  • Less exposure to stale account state: Fewer stored users mean fewer cases in which a disconnected device relies on an outdated local view.
  • Explicit availability architecture: VPN, DC reachability and local recovery become designed dependencies instead of silent assumptions.
  • Measurable state: Policy value, device class, Type-11 use and exceptions can be tracked as compliance data.
  • Preserves mobile productivity: A small, deliberate cache can support offline work without retaining the default ten users everywhere.

Disadvantages and limits

  • Lockouts are possible: A value that is too small or set to 0 blocks domain users when no DC is reachable before sign-in.
  • Remote recovery is difficult: A post-logon user VPN or emergency GPO cannot help if sign-in fails first.
  • The remaining cache is still exposed: 1 or 2 reduces quantity but does not make weak domain passwords safe.
  • No immediate offline enforcement: A device without DC connectivity does not initially know about a later account lockout, disablement or password change.
  • Not a general credential control: The setting does not cover active sessions, local accounts, service secrets, Vault content or browser credentials.
  • Credential Guard does not cover this verifier: It is not a reusable network credential and remains a separate protection decision.
  • Other sign-in methods need their own tests: Windows Hello, smart cards and hybrid trust models cannot be inferred from CachedLogonsCount alone.
  • Telemetry is delayed: Offline devices forward their logon events only after reconnecting.
  • Slots do not expire: The policy limits distinct users, not the age of an entry.

Typical pitfalls

  • Setting 0 across the domain without preparation: Mobile users and branch sites are locked out before a pre-logon path exists.
  • Treating the default ten as a security decision: An operating-system default is not a justified target for every device class.
  • Confusing slots with attempts or days: The value counts distinct users; it defines neither lockout nor expiry.
  • Expecting password changes to apply offline immediately: The local verifier updates only after that user successfully authenticates online on the device.
  • Assuming disabled accounts are blocked immediately: Without a DC, the device cannot validate the new account state.
  • Relying on a post-logon VPN: It starts too late to rescue a sign-in prevented by 0.
  • Failing to test a local recovery path: A corrective GPO is unreachable to a fully offline, locked-out device.
  • Using privileged domain accounts for recovery: This stores exactly the high-value identities the hardening effort should reduce.
  • Configuring security policy and Registry Preference in parallel: Two sources cause drift and complicate troubleshooting.
  • Testing only the primary user: Support, shared-device, provisioning and password-change scenarios remain undiscovered.
  • Assuming Credential Guard provides complete coverage: Cached domain verifiers are outside its protected reusable credentials.
  • Extracting cached users from system secrets: That creates unnecessary access to sensitive system data and is not required for policy control.
  • Documenting rollback only as a GPO link: A device without DC connectivity cannot retrieve that change.

Project checklist

  • [ ] Classify clients, PAWs, member servers, shared devices, VDI/RDS, kiosks and mobile devices separately.
  • [ ] Record effective CachedLogonsCount, policy source and local deviations for each device class.
  • [ ] Do not interpret a missing registry value automatically as 0.
  • [ ] Document normal user count, maintenance logons and real offline duration.
  • [ ] Validate DC, DNS, time and network paths before sign-in.
  • [ ] Distinguish a user VPN clearly from a device tunnel or pre-logon VPN.
  • [ ] Evaluate member servers and PAWs with a target of 0.
  • [ ] Pilot fixed clients at 0, 1 or 2 according to site design.
  • [ ] Test personally assigned mobile devices with a small value, typically 1 or 2.
  • [ ] Size shared devices separately using their real user population.
  • [ ] Create separate computer GPOs and leave the Default Domain Policy unchanged.
  • [ ] Remove Registry Preferences or local policies with a competing value.
  • [ ] Verify BitLocker, Secure Boot and device health as complementary controls.
  • [ ] Protect the local recovery account with Windows LAPS and monitor its use.
  • [ ] Test pre-logon networking and recovery during DC or VPN failure.
  • [ ] Account for the first online logon on newly provisioned devices.
  • [ ] Test password change, account lockout and disablement offline with test accounts.
  • [ ] Test Windows Hello, smart-card and password sign-in in the deployed trust model.
  • [ ] Collect event 4624 / Logon Type 11 centrally and baseline it by device class.
  • [ ] Treat CachedInteractive use on servers and PAWs as a reason to investigate.
  • [ ] Deploy in small rings with pilots that can be recovered locally.
  • [ ] Do not combine VPN, certificate and cache changes in the first rollout.
  • [ ] Document and test the last-known-good GPO and offline recovery procedure.
  • [ ] Track exceptions with owner, rationale, target value and expiry date.
  • [ ] Monitor policy drift, offline clients and help-desk cases after rollout.
  • [ ] Reassess targets when device type, site, VPN or provisioning changes.