A configuration that keeps a VPN connection active whenever the device is running. It improves continuity, but it also means the node’s trust and exposure persist across reboots, sleep states, and maintenance windows.
What Always-on VPN Means Operationally
Always-on VPN is not just a convenience setting, it turns remote access into a persistent control plane for the device. That means connectivity, policy enforcement, and trust assumptions are maintained continuously, so the design has to be evaluated as an always-present exposure path rather than an occasional user action.
For that reason, always-on deployment is most valuable where interruption would create unacceptable access gaps, but it also narrows the margin for error. If the tunnel is too permissive, the device can carry unnecessary trust into places it should not reach; if it is too strict, users may bypass the intended control or lose connectivity altogether.
Why Always-on VPN Changes the Security Model
The main security effect is that the VPN becomes part of the device’s baseline state. Instead of asking users to connect manually, the organisation is relying on a continuous encrypted path, continuous policy enforcement, and a stable trust relationship between endpoint, network, and security services.
That changes how defenders think about exposure. A device that is always connected can inherit internal reachability earlier in its lifecycle and keep it longer, so weak routing rules, split-tunnel mistakes, or poor segmentation matter more. VPN split tunnelling is a useful reference point because leakage and pivot risk become more consequential when the tunnel is meant to stay up all the time.
It also changes failure impact. If the VPN client, gateway, or policy engine is misconfigured, every reboot, sleep cycle, or reconnect event can become a repeat exposure event rather than a one-off inconvenience. VPN Security Guide covers the broader appliance and tunnel risks that make persistent connectivity safer or less safe in practice.
Exposure, Trust, and Session Persistence
Always-on VPN is closely tied to session persistence and device trust. When a device remains enrolled in the tunnel, the organisation must assume that the endpoint is continuously capable of reaching protected resources unless posture checks, route controls, and authentication state are actively enforced.
That matters because compromise does not have to start with a fresh login. If an attacker gains local control, steals a session, or abuses an already-connected device, the persistent tunnel can make lateral movement and internal reconnaissance easier. CitrixBleed 2 2025 is a reminder that session material, not just passwords, can sustain access across long-lived remote connections.
Always-on also increases the importance of device state on wake, reboot, and network change. If the client reconnects before posture validation or if fallback behaviour is too permissive, the system can briefly expose internal resources under stale assumptions. That is why remote access design needs to treat reconnect logic as a security control, not only a usability feature.
How Organisations Evaluate and Govern It
Organisations should assess always-on VPN as part of remote access architecture, not as a standalone client preference. The question is whether the always-connected model aligns with the sensitivity of the applications, the device trust level, and the operational need for uninterrupted access.
A useful governance lens is whether the VPN is still the right access model at all. In many environments, zero trust patterns reduce the need to extend broad network reach just because a device is authenticated. NIST SP 800-207 Zero Trust Architecture is relevant because it shifts the design discussion toward explicit verification, least privilege, and narrower access decisions.
Operationally, this means reviewing which users, devices, and applications truly need persistent tunnelling, and which can be better served by more constrained remote access patterns. The right answer is often mixed: some use cases benefit from continuity, while others only need access on demand.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-17 — Remote Access | Always-on VPN is a remote access control pattern that AC-17 governs. |
| IA-2 — Identification and Authentication (Organizational Users) | Persistent VPN access depends on strong user authentication at every valid session start. | |
| SC-7 — Boundary Protection | Always-on VPN shapes network boundaries and traffic flows that SC-7 is meant to control. | |
| Recommendation — Restrict remote access scope and enforce approved security controls for persistent VPN connections. Require strong authentication before allowing remote users to establish always-on access. Segment and filter tunneled traffic so the VPN does not create unnecessary internal reachability. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Always-on VPN is often evaluated against zero trust access models that reduce implicit network trust. |
| Recommendation — Replace broad always-on network trust with explicit verification and least-privilege access decisions. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Persistent VPN operation depends on secure configuration and management of network access infrastructure. |
| Recommendation — Harden and maintain VPN infrastructure so persistent tunnels do not expand exposure. | ||
Practitioner Guidance
Why practitioners should care: Always-on VPN changes the blast radius of a remote access control because the tunnel is assumed to be present whenever the device is active. Treat that as a continuous security posture decision, not a simple connectivity setting.
What to watch for: Pay attention to reconnect behaviour, posture checks after wake or reboot, route scope, and any signs that the tunnel is granting more reach than the user actually needs. Those are the points where persistent trust can quietly become persistent exposure.
Practitioner takeaway: Use always-on VPN only where continuity is worth the extra trust exposure, and keep the design narrow enough that persistent connectivity does not become persistent overreach.
Related resources from NHI Mgmt Group
- Guide: Remote Access Identity Guide
- How should security teams secure remote production workflows without relying on always-on VPN access?
- What is the difference between a VPN and an always-on zero-trust software-defined perimeter for roaming users?
- What is the difference between browser-based remote access and always-on VPN for enterprise users?
- When is a reverse proxy better than a VPN for access control?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org