TL;DR: This post is for IT admins who want the honest picture about Windows Pre-Login Connect — what it does, where it fits, and what to think through before you roll it out.
If you’ve been running into the limits of cached-credential logins or you’re evaluating whether always-on VPN is the right answer for your environment, Windows Pre-Login Connect (PLC) in OpenVPN Connect is worth a proper look. This post is for IT admins who want the honest picture — what it does, where it fits, and what to think through before you roll it out.
How Windows Pre-Login Connect (PLC) Works
Pre-Login Connect uses Windows’ built-in PLAP (Pre-Login Access Provider) architecture to add a “Network Sign-in” button to the Windows lock screen. When a user clicks it, they can initiate a VPN connection — including full authentication — before any Windows user session is active. The VPN tunnel comes up, and then they proceed with their normal Windows login.
The practical result: domain-joined Windows machines can authenticate against a domain controller over VPN exactly as if they were on the corporate LAN. Group Policy applies at login time. Logon scripts run. Cached credential edge cases go away.
This is different from always-on VPN, which keeps a persistent tunnel active regardless of user state. PLC is user-initiated at login. That distinction matters for your deployment model.
Where Pre-Login VPN Fits (and Where It Doesn’t)
PLC is the right tool if:
- You have remote or hybrid employees on domain-joined Windows machines who need to authenticate against AD at login.
- You’re seeing cached credential expirations, GPO failures, or broken logon scripts in your remote workforce.
- You want better user experience at login without the overhead of always-on VPN infrastructure.
PLC is not the right tool if:
- You need a persistent, always-active tunnel that survives user sign-out and doesn’t require user initiation — that’s service daemon mode.
- You need to enforce that VPN is always connected (PLC is not a security enforcement mechanism for persistent connectivity).
- Your users are on Windows ARM64 devices — PLC isn’t supported on that architecture.
VPN Authentication Methods Supported by PLC
One thing worth confirming before deployment: PLC supports a broad set of authentication types.
The one gap: profiles requiring ePKI (embedded PKI) certificate authentication are not supported in PLC. If your profiles depend on ePKI, test this before rolling out to your user base.
Deployment Model: Admin-Controlled Profiles
This is one of the more important things to understand. In standard OpenVPN Connect usage, users import their own profiles. PLC doesn’t use those profiles — it uses system profiles, which are configured by an administrator via command line and stored in a specified directory.
This is the right model for enterprise deployment:
- Users cannot add, modify, or remove profiles available at the login screen
- All profile management happens via admin tooling
- The profiles work at the system level, independent of any user account
The OpenVPN system service (ovpn_system_service.exe) handles installation, profile path configuration, and service management. There’s no UI configuration involved. If you’re managing deployments through MDM or endpoint management tooling, the command-line interface integrates cleanly.
Key Deployment Considerations for PLC
One active session at a time. If a user has an active VPN session within Windows, PLC cannot establish a connection. The system-level service and the user-level app don’t run concurrently. Build this into your user guidance.
Minimum version requirement. OpenVPN Connect 3.9 or later is required. If your fleet is on earlier versions, you’ll need to update before rolling out PLC.
Profile location. System profiles are .ovpn files stored in a directory you specify. Keep these organized and access-controlled, as they contain connection configuration.
Log access. PLC writes to ovpnsystemservice.log in the installation directory by default. For troubleshooting, Event Viewer also captures critical events under Windows Logs → Application (source: OVPNSystemService).
Protocol and security options. The system service supports the same configuration knobs you’d expect: VPN protocol (adaptive, TCP, UDP), DCO (data channel offload), TLS enforcement, and security level settings. These are configured per-service, not per-profile.
The Bottom Line for IT Admins
PLC solves a specific, well-defined problem: VPN connectivity at the Windows login screen for AD-joined environments. It deploys on top of existing OpenVPN infrastructure, doesn’t require always-on VPN architecture, and is fully admin-controlled.
If your environment matches the use case, this is a clean solution to a problem that tends to generate disproportionate support noise relative to its actual complexity. The deployment path is straightforward if you’re comfortable with command-line service management.
Full setup guide and configuration reference →
Start a trial or talk to our team →
Ready to see how OpenVPN can help protect your organization from attacks?
Try the self-hosted Access Server solution or managed CloudConnexa service for free, no credit card required.
See Which One is Right for You
