Saved VPN on Android: Which Secret Can You Recover?
A phone that reconnects without asking for a password is not storing one you can copy. Compare the four credentials and the recovery each one needs.
The phone reconnects to the VPN every morning without asking for anything. That implies the credential is in there somewhere. It usually is not, at least not in a form you can read out and type into a new device.
What the phone has is authority to connect. What you want is a secret you can carry across, and those are different properties that happen to produce the same behaviour on screen.
Before you reset anything, identify which of four kinds of secret is actually missing, because each one has a different owner and a different recovery.
A working connection is not a stored password
An app that reconnects silently may be holding a password, a session token, a certificate reference, or nothing more than a device-bound key it cannot export. All four produce the same user experience and none of them are interchangeable.
A row of dots in a settings field is a rendering decision, not evidence. Some apps genuinely store a recoverable password and offer a reveal or export; others take a token from a single sign-on flow and never see the password at all.
So the first question is not where the file is. It is what kind of authority the app was granted, and that answer comes from the provider rather than from the device.
Four secrets, four recoveries
Match your situation to one row before contacting anyone, because the request changes completely depending on which it is.
| What is missing | Who can restore it |
|---|---|
| Account password used with a username | The identity provider, through a reset |
| Password protecting a private key or PKCS#12 package | Nobody, if it is forgotten; a fresh profile and key are issued instead |
| Session token or SSO session | Nobody; sign in again to obtain a new session |
| Reference to a certificate or key held on the device | The administrator, by enrolling the new device |
The second row catches people most often. A PKCS#12 import password protects key material and is unrelated to the account login, so resetting the account password recovers nothing. If the package password is genuinely lost, reissuing is the fix.
The fourth row explains a lot of confusing support threads. The profile may reference a credential in the platform key store rather than contain a portable copy, in which case there is nothing in the profile to extract even in principle.
Why copying app data usually fails
The old recipe is to pull the app's data directory and read the configuration out of it. On current Android the recipe has two independent problems.
The first is backup policy. Android 12 restricted app data exported through the legacy adb backup path for apps targeting API 31 or later, and applications can exclude data from backup entirely. A procedure written for an older device is not a universal recovery method for a current one.
The second is the key store. Keys generated there can be non-exportable and hardware-bound, as the Android Keystore documentation describes. Copying an encrypted blob does not copy the key that decrypts it, so a restored directory can contain a credential that the new device can never use.
Neither problem is a bug to work around. Both are the platform doing what it was designed to do, and treating them as obstacles tends to end with a rooted phone and no password.
Move to a replacement phone deliberately
Do the supported thing first. If the provider offers an export that explicitly includes the credentials you need, use it and verify the result on the new device before wiping the old one. If it does not, request a new profile or enrolment, which is the normal path for certificate-based services and usually takes less time than the workaround.
Sequence matters. Enrol the replacement, connect it, push a test request through the tunnel, and only then retire the original. Keeping the working phone until the new one is proven is the cheapest insurance available, and it costs nothing but patience.
Plan for the side effects of a reset too. If the account password is reset or the device identity is revoked, other sessions may be invalidated, including a laptop client and a tablet that nobody remembered. Deal with those in the same window rather than discovering them one at a time.
What not to do
Do not root the only working device to hunt for a plaintext file. You convert an access-recovery problem into a device-integrity problem, you may break the app's own integrity checks, and you still have no guarantee that the value you are looking for exists in readable form.
Do not paste private keys, exported profiles or passwords into a support ticket to prove the problem is real. The provider needs the profile name, the app version, the account identifier and the error, none of which are secret.
And do not disable certificate verification to get a connection while you wait. That trades a temporary inconvenience for a permanent weakening of the only check that tells you which server you are talking to. Record the four facts, ask the specific question, and use the issued path.