Rotate a VPN Password Without Locking Out Every Device

Three phones, a router and a monitoring check are still holding the old password, and one of them reconnects every ninety seconds. The account password changed ten minutes ago, so every one of those clients is now submitting a value the server rejects. That is the moment the myth breaks: a password change touches the account, not the copies of the old value sitting on each device. What follows is the work the change did not do.

The myth: one change, everywhere at once

The belief is that a password change signs everything out and forces a clean re-login. It does not, because the server only tracks which credential it last accepted while the clients keep whatever they stored. A device with a saved password retries it on its own schedule and fails quietly until somebody notices the account is locked. Once you accept that the copies live outside the account, rotation stops looking like a single action.

None of that argues against rotating. It argues for treating the saved copies as part of the change instead of an afterthought. A lockout usually comes from parallel retries: each device keeps submitting the old value on its own schedule until the counter trips. The account then looks attacked while it is only being offered credentials nobody replaced. That distinction matters, because the fix is a list of devices rather than a stricter lockout policy.

Inventory the copies before you rotate

Write the inventory before you open the password form. List every client, script, automation and managed profile that authenticates as this account: the phone that connects on its own, the router configured two years ago, the laptop that only wakes on Mondays, and the monitoring check that tries every minute. For each one, note where the credential is stored, whether the device can be reached during the change, and what recovery route exists if it cannot reconnect. That list is what turns a risky change into a scheduled one, and it has to exist before the old password stops working.

Offline devices are the classic miss. A laptop in a drawer returns three weeks later and presents the stale value at the worst possible moment. Note its location and its schedule too, because you will have to chase it rather than wait for it.

On a Linux fleet the search is mechanical rather than clever. Look for profiles that reference a credentials file, then look for the credentials files themselves, because the second list is the one that has to be rewritten. Repeat the exercise for desktop clients and phones, where the store is a profile or a keychain entry rather than a path. The goal is a list you can work through, not a scan that claims to find every copy.

grep -rl auth-user-pass /etc/openvpn /etc/NetworkManager
grep -rl auth-user-pass ~/.config 2>/dev/null

Count the copies against the people who own them. A device nobody claims is a device nobody will update, and it is also the one most likely to keep retrying.

Which secret you are actually rotating

An account password is only one credential in a VPN deployment. A key passphrase, a certificate identity and an optional peer secret each have their own replacement path and their own owner. Changing the account password does nothing for a device that authenticates with a certificate, and reissuing a certificate does nothing for a client holding a saved password. Name the secret before you name the fix.

If the rotation is driven by suspicion rather than by policy, the incident process outranks the convenience plan. Revoke what the evidence requires and accept the extra work on the device list. That decision belongs to the incident owner, not to whoever happens to be holding the password reset form.

Replace the stored value where it lives

Change the credential through the mechanism the service documents, then update the saved copy or run the sign-in flow on every device you intend to keep. Do not edit a generated configuration behind a manager that rewrites it, because the manager restores the older value on its next run and the edit becomes a delayed failure. Update the source the manager reads, or use the client's own credential store. Either way, the device has to end up with the new value in the place the client actually reads.

A client that stores a password file needs the file rewritten, while a client that prompts needs a completed sign-in. NetworkManager keeps the secret inside the connection profile, so the change goes through nmcli rather than a text editor:

nmcli connection modify work vpn.secrets "password=NEW"
nmcli connection up work

A profile that reads a credentials file is a third case. Replace the contents of that file, keep its permissions closed, and reload the client instead of editing the profile that points at it. The profile did not change; only the secret it reads did.

Reconnect each intended device once, deliberately, and watch which ones fail. If a device keeps failing, look at the account it is pointed at and at the store it reads before changing the password again, because a second change multiplies the copies that need updating. A device that fails twice is usually pointed at the wrong account or reading a store you have not found yet. Fix that, then reconnect.

Sessions and tokens outlive the password

Changing the password does not prove that existing sessions or separate certificates were revoked. Some services keep a session alive until it expires or is terminated explicitly, and issued tokens carry their own lifetimes. Check what the service actually does instead of assuming the change was global. If the change was driven by suspicion, terminate the sessions explicitly and confirm the result.

The credential lifecycle guidance in NIST SP 800-63B keeps authenticators and sessions in separate categories, which is why a password change and a global logout are different operations. Treat them as two tasks with two completion criteria. The first is finished when the new value works, and the second is finished when the old sessions are gone.

Record the completion without writing the new password into the record. A rotation log that contains the credential is a new incident waiting on a shared drive. Note the date, the devices updated, and the devices still outstanding.