Why a domain laptop accepts the old password offline

A password change lands everywhere at once, except on the one laptop that has been offline for a week. Webmail takes the new password, a desktop in the office takes it, and the remote machine still signs in with the old one when the VPN is down. That is not a second password and not a sync bug in the directory. It is the cached logon verifier doing what it was designed to do, and the fix is a sequence rather than a reset.

The laptop is checking a cached verifier

Domain-joined Windows keeps a local verifier for recent successful interactive logons so the machine can start when no domain controller answers. That verifier is derived from the password as it stood at that logon. Changing the password elsewhere updates the directory, not the copy on a laptop that has not talked to it since.

So the old password can still open the local session while being invalid for any fresh domain authentication. Those are two different observations, and mixing them leads to repeated resets.

Confirm which credential is actually in play before changing anything else. A Windows Hello PIN, an Entra ID sign-in, and a traditional domain password are separate mechanisms, and the PIN in particular is not the domain password even when it unlocks the same desktop.

Network authentication is not interactive logon

Opening a file share with the new password proves the network path works. It does not refresh the interactive logon cache, because Windows treats network and interactive authentication as separate operations with separate state.

The verifier refreshes only when an interactive logon actually contacts a domain controller; a mapped drive or an Outlook prompt does not do it.

That distinction explains the usual report: the user can read mail and open the intranet, yet the lock screen still wants the old password. It also explains why a VPN started after sign-in cannot help the initial logon, since the tunnel arrives after the decision has already been made locally.

Get one online sign-in at the right moment

The cache refreshes when the user signs in interactively while the domain is reachable. For a remote machine, that means the tunnel has to exist before the credential is evaluated, not after the desktop appears.

Check whether the deployment supports pre-logon connectivity or a device tunnel. Those are designed for this timing, and a user tunnel is not a substitute:

nltest /dsgetdc:corp.example
klist

If the endpoint has no pre-logon path, use whatever supported recovery process the organization documents. Some environments use a connect, lock, and unlock sequence with the tunnel held open at the lock screen; others send the device to a managed recovery step. Follow the one that matches the client, and confirm the tunnel survives the lock screen before relying on it.

Protect the way back in

Before signing out of a remote machine, decide how the next sign-in will reach the domain. A user tunnel that drops with the session can remove the only path you were counting on, and then neither the old nor the new password gets you past the lock screen. Keep a local administrative account or an out-of-band console as the fallback. Write the recovery step down where the user can reach it without signing in.

For support, collect four facts: where the password changed, which credential still works offline, whether a domain controller is reachable through the tunnel, and which sign-in method the laptop uses.

Those four separate a stale verifier from an account lockout or a rejected VPN sign-in, which look similar in a ticket and have different fixes. A locked account will reject the new password online as well, so test that before blaming the cache.

Close the loop with one online sign-in

The goal is one supported interactive sign-in while the domain is reachable, followed by a known offline state. That single event refreshes the verifier and ends the cycle of changing the password on every device.

Verify the state afterwards with the cached-logon count and a domain controller lookup:

reg query "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon" /v CachedLogonsCount
nltest /sc_verify:corp.example

If the count is zero, cached logon is disabled by policy and the offline behavior will not change no matter how many times the password is reset. That is a policy decision to raise with the owner, not a workaround to apply locally.