iPad VPN Without Password Prompts: Certificates vs Saved Login
A saved password and a device certificate remove the prompt in different ways. Compare them, then choose separately what makes the tunnel open.
"Stop asking me for a password" is really three requirements bundled into one complaint, and an iPad deployment answers them in different places. The prompt comes from authentication, the timing comes from activation, and the coverage comes from enforcement. Pick the credential that removes the prompt, then pick separately what decides when the tunnel opens. Mixing the two decisions is how people end up with a saved password on a profile that still waits for a tap.
| Saved or shared secret | Device certificate | |
|---|---|---|
| What the user sees | no prompt while the credential stays valid | no prompt, no password to rotate |
| What the admin manages | the secret in the profile and its distribution | enrollment, expiry and revocation per device |
| Typical failure | gateway demands a second factor | expired or revoked certificate |
Two problems wearing one complaint
A native IKEv2 configuration on iPad can reference a password or a certificate, and the AuthenticationMethod key decides which one applies while PayloadCertificateUUID names the credential that supplies the identity. Which of those the gateway will accept is a server policy question, not a client preference. So the first thing to establish is what the VPN service permits, because an iPad cannot negotiate its way to a method the other end refuses.
Only after that does it make sense to talk about when the tunnel activates, which is a different set of profile keys entirely.
Option one: a credential the iPad can reuse
A stored account password or a shared secret satisfies a gateway that authenticates the user or the group, and it removes the prompt for as long as the secret stays valid. Its weakness is lifecycle: the secret sits in the profile, several devices may share it, and rotating it means touching every profile that carries it. If the service also demands a one-time factor or an interactive approval, no local setting converts that policy into an unattended login.
A password saved by one app is also not automatically available to a different VPN implementation, which is why the same account can stop prompting in one client and prompt every time in another.
Option two: a device certificate with its own key
A certificate removes the prompt in a stronger way, because the iPad proves possession of a private key instead of replaying a secret. That requires the leaf certificate and its key to arrive through the approved enrollment path, and it requires the gateway to accept certificate authentication for that connection. Importing a CA certificate alone gives the device trust material and nothing else, which is a common and quiet failure.
The trade is lifecycle work. Each iPad gets its own identity so a lost device can be revoked without reissuing the fleet, and expiry dates become real operational events. A certificate that silently expires looks exactly like a VPN outage on the morning it happens.
Choose by what the gateway accepts, not by preference
Ask the VPN administrator two questions: which authentication methods the service accepts for this client type, and whether any of them require interactive input. If the answer is certificate only, plan enrollment and renewal. If the answer is password plus a second factor, accept that the prompt is policy and stop treating it as a device fault. If both are accepted, certificate wins on lifecycle for a supervised fleet and password wins on setup effort for a handful of devices.
Write the chosen method into the deployment record alongside the profile identifier, because the next person to touch the profile will otherwise pick the other one.
Then separate activation from authentication
VPN On Demand opens the tunnel when a configured condition matches, whether that is a DNS domain, an interface type or a joined network, and Apple documents it as requiring no user interaction. That is a good fit for private resources that should become reachable only when something asks for them. It is not the same as managed Always On, which keeps coverage enforced and comes with its own supervision and profile requirements.
A working credential does nothing for either one. Plenty of iPads hold a perfectly good certificate and still wait for a manual tap because no on-demand rule ever fired.
Hand the requirement over in a form an administrator can act on: this iPad should reach these resources with no recurring user input, using this credential type, under these activation and outage rules. If the current service cannot meet those conditions, repeated prompts are the policy working as designed.