Saved VPN Password: Who Can Decrypt It and When

A VPN client that shows an encrypted password in its XML has told you almost nothing. The ciphertext answers only that the value is not stored as plain text in that representation. Who can decrypt it, with what key, and under which user context are the questions that decide whether the storage helps. Answer them before you call the file safe or unsafe.

Establish what object is stored

Start with the product's documented storage model. A client may store a recoverable password, a token, or a reference to a credential store, and each has a different exposure. The XML element name is not the design, and a base64-looking string is not proof of encryption either.

Ask the vendor or administrator which component reads the value at connect time.

Then identify the protection API if it is documented. On Windows, CryptProtectData protects data with a key derived from the encrypting user's logon credentials, and its machine-scoped option changes who can decrypt. That is a concrete example of why the scope matters. It is not evidence that any particular VPN client uses that API.

Separate a stolen copy from runtime use

A client that reconnects without asking you needs a supported way to recover the credential. Protecting a backup copy does not remove that capability. Any program running in the right user context may be able to use the same path, which is why the endpoint itself sits inside the trust boundary. File permissions and process privileges narrow that boundary; they do not remove it.

That distinction is what an offline-file claim usually gets wrong. Encryption at rest can stop someone who copies one file without the account. It does not stop code that runs as the account.

Both statements can be true at once, and the second one is the one that matters during incident response.

Read the access controls that actually apply

Check the file's ACL and the directory above it, not only the file mode. On Windows, compare the effective permissions of the user profile with those of the client's service or scheduled task. A secret protected for one user is not automatically protected from an administrator, and it is not automatically exposed to one either.

icacls "%APPDATA%\Vendor\Client\profiles.xml"
whoami /priv

Record which identity runs the client, because that identity is the decryption subject.

For a managed fleet the relevant control may be device management rather than the file. Ask whether the credential is escrowed, whether it can be revoked remotely, and what the process is when a device is lost.

Plan for exposure instead of testing decryption

Do not run an unfamiliar extraction tool against the file to prove a point. It may work, it may damage the profile, and either way it changes the evidence. Use the documented design and an authorized assessment if verification is genuinely required.

If exposure is established, rotate the credential at the identity owner.

Deleting the saved entry is not revocation. It can stop that client from offering the value again, and it does nothing about a copy already taken or a session already authorized. Replace the credential, end the sessions the owner can end, and record what was rotated and when.

The questions for a vendor review

Ask what secret is stored, which component uses it, which user or machine key protects it, which access controls apply to normal use and backups, and how saving policy and remote invalidation are handled. Those five answers describe the design; the XML does not.

Keep the answers with the deployment record so the next reviewer does not repeat the exercise.

A saved credential is a trade between convenience and exposure. Make the trade deliberately, and write down who accepted it.