Android Keeps Asking for a Password After VPN Setup
Resetting a VPN account cannot unlock an Android screen. Work out which prompt you are facing, then pick a recovery path that fits.
Resetting your VPN account password will not clear an Android screen lock, and that mismatch explains most of these dead ends. The lock screen, a work-profile policy and the VPN credential are three separate secrets, held by three different parties. Before you reset anything, work out which one the prompt is asking for. Three signals settle it: whether you can use the phone at all, when the prompt appears, and whether someone else enrolled the device.
Three signals that identify the prompt
Access is the first signal. If the phone boots to a lock screen you cannot pass, nothing inside Android is reachable, and no account console changes that.
Timing is the second. A prompt that appears while the phone is still starting, before any app is drawn, belongs to the device or to a storage policy that runs at boot. One that appears only after you tap the VPN profile belongs to that profile's authentication. A screen with a keypad, a fingerprint icon and an emergency-call button is the system lock screen, whatever text sits above it.
Enrollment is the third. Open Settings, then Security, then Device admin apps; a managed phone will list something you do not recognise, and that name is who to call.
Match the wording to the store that owns it
Vendor wording is inconsistent between clients, so read the sentence doing the asking rather than the heading above it. The table below places the prompts that come up most.
| What the prompt says | Who owns it | Who can fix it |
|---|---|---|
| Screen lock, PIN, pattern or fingerprint | The device | The device owner, via the platform erasure route |
| Certificate, credential or keystore password | Android credential storage | Whoever holds the key bundle, after a fresh import |
| Sign in to your organisation | Device policy controller | The administrator who enrolled the phone |
| Username and password for the profile | The VPN service | The account holder, through the provider reset flow |
The two middle rows cause most of the confusion. Certificate or credential wording means Android's own credential storage wants the screen lock that protects private key material, which is why a VPN setup flow can demand a password for the phone itself. Nothing in that dialog is asking the VPN server for anything.
When the prompt is the VPN credential
If the phone is usable and only the tunnel refuses you, stay inside the VPN layer. A password reset on the provider side is the right first move, and it is enough for a profile that authenticates with a username and password. Remove the saved profile and add it again from a fresh configuration file or QR code, because saved profiles keep replaying the old credential and make the reset look useless.
One test separates the two layers quickly. Try the same account from a laptop. If the laptop connects, the account is fine and the phone is holding stale material. If the laptop fails the same way, the reset never took effect and the phone was never the problem.
Certificate-based profiles fail differently. A PKCS#12 bundle or a per-device certificate is bound to a private key in the phone's keystore, and changing your account password does not regenerate that key. So when the client asks you to choose a certificate and the list is empty, no key was ever imported for this device, and a new enrollment is the only repair.
When the screen lock is what you lost
Older guides promise a remote command that replaces an existing password on the phone. It does not exist any more, and the forgot-pattern button people remember from Android 4.4-era devices went with it. Google's current locked-device guidance is blunt: when the screen lock cannot be recovered, the supported route erases the phone and sets it up again.
Erasure has prerequisites worth checking before you commit. The phone needs connectivity, the signing-in account has to match the one previously added, and remote erase has to have been enabled on that handset beforehand. A manufacturer button combination is another documented route, and it carries the same cost.
Assume data loss unless you can name a specific backup and the date it last ran. Post-reset protection can ask for credentials from the account that was on the phone before, and a cloud backup does not reliably restore app-bound keys or a managed profile's identity.
Count the downstream cost before wiping a phone that still works: a work-profile identity has to be reissued by an administrator, banking and authenticator apps need re-registration, and a device-bound VPN certificate needs a new enrollment.
Work through it in this order
Start at the top and stop at the first step that changes the behaviour. Read what the prompt actually says, then confirm whether an administrator enrolled the device, then test a freshly imported profile, and only then treat the lock screen as lost. Writing the wording down before you call support saves a round trip, because it asks for my password describes four different repairs.
If you reach the erase step, confirm the account credentials and the backup situation first, and re-enroll the VPN afterwards instead of restoring a profile from a backup that predates the reset.