Password prompts from a VPN client look interchangeable and are not. Four distinct actions hide behind a similar dialog: writing files into a protected location during installation, adding or changing a network configuration, activating a system extension that carries traffic, and complying with a policy that a management server already set. Each has a different owner, a different blast radius and a different way to verify that it worked. Matching the message you see to one of those four is the whole exercise.

Three Different Approvals Look the Same

Installer authorization is the simplest case: a package writes into directories a standard user cannot modify, and macOS asks for administrator credentials to permit it. The system is not deciding whether the software is safe; it is deciding whether you may write there. That is also why a package can install cleanly and still be useless: installation approval says nothing about whether the code will be allowed to run afterwards. Once installed, the app may still need a second approval before it can influence networking.

Network configuration authorization covers changes to the system's connection list. Adding a VPN service, or changing settings that a network administrator configured, requires elevation because those definitions affect every account on the machine. This approval grants configuration authority, not traffic authority.

Extension approval is the one that matters for how packets travel. A modern client installs a system extension that macOS loads into the system, and macOS requires an explicit decision in Privacy & Security or Login Items & Extensions before activating it. A fourth case is a managed Mac, where a policy already pre-approves the extension and the user sees no dialog at all.

What Each Approval Actually Changes

An installer changes files on disk, and its consequences end when the files are removed, apart from leftovers. A network configuration adds a service definition that appears in the connection list and may be reactivated by on-demand rules. An extension approval changes what code the system will load and keep running, which is why it survives uninstalling the visual application in some workflows. Removing an app bundle does not always remove its extension, and an extension left behind keeps its networking privileges.

The distinction predicts the symptom. Installed but never connecting usually means the extension is approved nowhere; connecting but with settings that revert at the next change usually means a management policy owns the definition.

Signature and Publisher Decide the Answer

Before approving, read who signed the thing rather than what the dialog's icon suggests. Two local checks are enough to see the signing authority and whether the system's assessment passes on this machine.

codesign -dv --verbose=2 /Applications/ExampleVPN.app
spctl -a -vv /Applications/ExampleVPN.app

An unsigned or unnotarized bundle is not automatically malicious, but it deserves a different decision than a signed one from the vendor you intended. A package that arrived through a message rather than from the vendor's own site is the case where the answer is simply no.

Compare the team identifier against the vendor's published identity rather than trusting the app's display name, since names are easy to reuse and identifiers are not. If the vendor publishes the identifier in its installation guide, that page is the reference for the comparison and also the place where a mismatch should be reported. A client from a reseller, a repackaged build or a portable copy from a forum deserves more suspicion than the same vendor's signed download.

When a Policy Owns the Decision

On a corporate Mac the administrator may have already decided. A management profile can deliver the VPN definition, pre-approve the extension and lock the connection so it cannot be removed. In that arrangement the request to enter a password is often a request to override a decision that was never yours.

Lowering startup security or detaching management to force an installation changes the machine's threat model permanently to solve a temporary problem. That trade is rarely made consciously; it usually happens while following a forum post. Ask the administrator for the supported path instead, which may be as simple as resending the profile or approving the extension on the server side. If the administrator cannot approve it, that answer is the finding, not an obstacle to route around.

Confirm the State After Approving

Once an authorized approval is given, verify what the system thinks rather than what the client claims. The extension list reports activation state without needing any third-party tool.

systemextensionsctl list

An entry shown as activated belongs to the team identifier you checked earlier; an entry shown as terminated waiting for user approval explains a client that starts and never carries traffic. If the prompt returns after every attempt, capture the exact message and the client version, because a repeating approval usually means the extension is being replaced without the previous one being deactivated, and that is a support case rather than a password problem. Note the version before calling support, since the fix may already exist in a newer build and the conversation will start there.

Zvinyorwa zvakafanana