Before-Login VPN on macOS: Unlock, Login Window, Session
FileVault unlock, the login window and a user session are separate stages. A desktop client that starts at login solves only the last of them.
Here is a belief that costs people a week: that a Mac has one moment called before login, and that a VPN client either starts then or does not. The machine actually has at least three moments where network access matters, separated by who is permitted to hold credentials at that point. A client launched from a Login Item covers exactly one of them, and it is the last.
The myth that one setting covers the whole boot
Read the product page again and look for which stage the feature names. A checkbox labelled start at login means a login item, which runs after a user session exists. A checkbox labelled connect on demand means the client opens a connection when traffic matches a rule, which still requires the client and its credentials to be available.
Neither of those reaches the boot process. That is not a limitation the vendor forgot to remove; it is what the operating system allows. Before the volume is unlocked there is no running system to launch a client from, and after logout the user's secrets leave with the session. Two separate walls, and neither one yields to a different checkbox.
Once you separate the stages, the original question changes shape. Instead of asking whether the VPN starts before login, you ask which of three specific moments has to work, and then you discover that each one has a different owner: the encryption stack, the network extension, or the user session.
What actually happens at each stage
Startup begins with an encrypted volume that has to be unlocked before there is a usable system to run anything general purpose. That unlock happens in a restricted context with a restricted set of credentials, and Apple documents plainly that encrypted data stays inaccessible without a valid unlock.
Next comes the login window, where the system is running but no user session exists yet. A user-context extension has already ended if the user logged out, and a global system extension may still be running, but running is not the same as holding the credentials your VPN needs.
Then comes the session, where a normal client can read the login keychain, prompt for a second factor and apply pushed routes. Most features people describe as pre-login are actually this stage, triggered early in the session rather than before it.
| Stage | What it can use | What it cannot do |
|---|---|---|
| FileVault unlock | Credentials supplied at the console to unlock the volume | Run an ordinary VPN app or read a user keychain |
| Login window | System context, possibly a joined network | Use a user secret that only exists after login |
| User session | Login keychain, interactive MFA, full client features | Exist before the volume unlocks |
Why a launch daemon cannot sign in for an absent user
Elevated privilege feels like it should solve the problem, and it does not. A launch daemon runs as a system process with no user session behind it, so there is no keychain to unlock and no human to answer a prompt. It can open a socket and read a file; what it cannot do is become the user who owns the credentials. Privilege is not identity, and this is the exact point where the two get confused.
What people build in that gap is a script with a password in it, which is a worse problem than the one they started with.
The honest version of the requirement is narrower. If the machine must reach a protected resource while nobody is present, then the identity that resource accepts has to be one the machine can hold without a person: a device certificate, a credential in the system keychain, or an account whose second factor is not a push to a phone in someone's pocket. Design that identity deliberately, and the stage question usually answers itself.
The Windows pre-logon feature does not transfer
Windows has a documented pre-logon access mechanism for some remote access products, and the name travels better than the capability. A feature described in a Windows deployment guide tells you nothing about whether the same vendor implements an equivalent on macOS.
Ask for a statement covering the Mac hardware, the macOS release, the client version and the authentication method you actually use. A general claim of support is not enough, because the difference between working and not working often sits in one of those four.
If the vendor cannot answer, that is the answer. Plan for the session stage and design an alternative for the unattended case, rather than discovering the gap during a rollout.
What to ask for instead
Write the requirement in the language of the stages. Which resource, needed by whom, in which context, and with what acceptable delay when the connection is not there yet?
If the answer is a user who signs in and then needs the tunnel, connect-on-demand and a startup item are sufficient and inexpensive. If the answer is a machine that reboots overnight and must report in, the design needs a supported disk unlock path, a device identity and a recovery process that works when the network never comes up. If the answer is organisation sign-in that depends on the tunnel, then the login, identity and VPN designs have to be built together rather than purchased separately.
Apple's FileVault documentation is the right starting point for the unlock stage. Everything after it is a client and identity question that a vendor statement should settle before you buy.