One Device Still Fails After the VPN Password Reset

You reset the password, tested it in the portal, and one laptop still cannot connect. The instinct is to reset it again, which is how an account gets locked and a stale secret becomes an incident. A VPN client rarely asks for a password each time; it asks once and stores the answer somewhere you did not choose. Finding that place is the whole job, and it is faster than another reset.

Confirm what each client is actually sending

Check the account, domain and gateway on the failing client before assuming the password is the problem. A web portal login can use a different identity system from the VPN itself, so a successful portal sign-in says nothing about the protocol's authentication. Some deployments accept an email at the portal and a different username at the tunnel. Confirm which identity the client is configured to present before you reset anything.

Read the error text and classify it. A certificate failure, an expired challenge or an unsupported cipher is not a stale password, and treating it as one produces a reset loop with no effect. If the service has a lockout policy, stop after two or three failed attempts and confirm the account state before continuing.

Enumerate the stores instead of guessing

Four stores hold a VPN secret, and the table below maps each one to where the value survives and what clearing it actually means. A native OS profile keeps the secret in the platform credential store, which is why the entry can outlive the application that wrote it. A client configuration file keeps the value where that client reads it, either inline or in a referenced auth file, so editing a different file changes nothing. A browser portal cookie and a policy-delivered credential live somewhere the device does not really own, which decides who is allowed to change them.

Check them in a fixed order: the OS credential store first, because it is the one the client consults by default, then the client's own vault or config file, then the browser session, and finally the policy that can overwrite all three. The order matters because a later store can silently restore an earlier one, and you will have fixed the wrong layer while the failure persists. Write down which store you changed, because that note is what makes the next reset a two-minute job instead of an afternoon.

Look in the store the client actually uses

Read before you delete, so you know which entry belonged to the VPN. The commands below list and inspect rather than remove, which keeps the diagnosis reversible.

# Windows credential store
cmdkey /list | findstr /i vpn

# Windows native profile
Get-VpnConnection -Name "Work" | Select-Object -ExpandProperty Guid

# macOS Keychain
security find-generic-password -s "Company VPN" -g

# Linux NetworkManager
nmcli -s connection show "Work" | grep -i password

On Linux, -s shows secrets that NetworkManager otherwise hides. On macOS the Keychain command prints the stored item, so treat the terminal scrollback as sensitive. If the failing client is a third-party app with its own vault, the OS store will look correct while the app keeps its own copy, and that vault is where the change belongs.

Handle the devices that are offline

Laptops that wake up and reconnect unattended will keep presenting the old secret for as long as their copy exists. Plan the update so those devices are corrected before they retry in a burst, and consider disabling auto-connect on the affected profile until each one has been through the supported flow.

For a managed fleet, change the value where the policy is defined. Editing a local copy on a device whose credential is provisioned centrally is temporary at best; the next policy refresh restores the old value and the failure returns without explanation.

Verify with one controlled attempt

Update the intended entry, reconnect once, and confirm the tunnel reaches something specific. One controlled attempt produces a usable error if it fails, while twenty produce a locked account and a mystery. If a client still fails after the store is corrected, capture a single non-secret error and stop. Keep that error with the device name so the next shift starts where you finished.

A password change does not touch certificates, session tokens or MFA enrolment, and those are separate identities with their own lifecycle. A renewed certificate is not fixed by rotating a password, and a token issued before the reset may still be valid. Finish by writing down which store held the stale value, because the next reset will hit the same list.