# Secure Remote Access
Secure remote access is the set of technologies and policies that enable users to access organizational systems and data from locations outside the corporate network while maintaining security controls equivalent to (or better than) on-premises access. Remote access is no longer an exception for traveling executives. It is the default working mode for a significant portion of the workforce.
The shift to remote and hybrid work that accelerated during 2020 made remote access the primary access model for many organizations. Pre-2020, remote access was a VPN tunnel that a fraction of the workforce used occasionally. Post-2020, remote access is the daily working mode for 30% to 70% of the workforce, depending on industry. This shift fundamentally changed the security model: the corporate network perimeter is no longer the primary trust boundary because most users are outside it most of the time.
Remote access security has evolved through three generations. VPN (Virtual Private Network) extends the corporate network to the remote user's device, placing them "inside" the perimeter. ZTNA (Zero Trust Network Access) provides application-specific access without extending the network, verifying identity and device health for each access request. SASE (Secure Access Service Edge) converges ZTNA, cloud security, and network optimization into a unified cloud-delivered platform. Each generation reflects a deeper integration of zero trust principles into remote access architecture.
VPN creates an encrypted tunnel between the remote user's device and the corporate network. Once connected, the user's device appears to be on the corporate network and can access internal resources as if physically present.
IPsec VPN. The traditional site-to-site and remote access VPN protocol. IPsec operates at the network layer (Layer 3) and provides strong encryption (AES-256) and authentication. IPsec VPN concentrators (Cisco ASA/Firepower, Palo Alto GlobalProtect, Fortinet FortiGate) terminate VPN connections at the network edge.
SSL/TLS VPN. Operates at the application layer (Layer 7) using TLS encryption. SSL VPN is more flexible than IPsec (it works through most firewalls and proxies because it uses standard HTTPS ports) and is the most common remote access VPN implementation.
WireGuard. A modern VPN protocol that is simpler, faster, and more secure than IPsec and OpenVPN. WireGuard uses state-of-the-art cryptography (ChaCha20, Curve25519, BLAKE2s) and has a minimal codebase (approximately 4,000 lines of code versus hundreds of thousands for IPsec implementations), which reduces the attack surface.
VPN limitations: VPN provides network-level access. Once connected, the user can reach any resource on the corporate network that the network configuration permits. This is over-permissive for zero trust: a user who needs access to one application receives access to the entire network segment. VPN also extends the corporate network to the user's device, which means the device's security posture directly affects the corporate network (malware on the user's device can traverse the VPN tunnel to reach corporate resources).
ZTNA replaces VPN's network-level access with application-level access. Instead of connecting the user to the network, ZTNA connects the user to a specific application after verifying their identity and device health. The user never has network-level access. They can reach the authorized application and nothing else.
Identity-centric access. ZTNA verifies the user's identity (through SSO and MFA) and evaluates the user's authorization (does this user have permission to access this specific application?). Access is granted per application, not per network. A finance user who is authorized for the ERP system can access the ERP. They cannot reach the engineering servers, the development environment, or the database tier because ZTNA does not provide network connectivity to those resources.
Device posture verification. Before granting access, ZTNA evaluates the device's security posture: is the device managed (enrolled in MDM/UEM)? Is the OS current? Is endpoint protection running and current? Is full-disk encryption enabled? Is the device jailbroken or rooted? Devices that fail posture checks are denied access or granted limited access (web-only, no data download) until compliance is restored.
Continuous evaluation. Unlike VPN (which authenticates once at connection and maintains the session), ZTNA continuously evaluates the session: is the user's behavior consistent with their baseline? Has the device posture changed during the session? Has the risk level changed (a new threat intelligence indicator matching the user's activity)? If conditions change, the session can be terminated or the access scope reduced in real time.
ZTNA implementations. Cloud-delivered ZTNA (Zscaler Private Access, Cloudflare Access, Palo Alto Prisma Access, Microsoft Entra Private Access) routes user traffic through the vendor's cloud infrastructure, where identity verification, device posture checks, and policy enforcement occur before the traffic reaches the application. The application is never directly exposed to the internet. The ZTNA service acts as a broker between the user and the application.
SASE converges ZTNA, cloud security (CASB, SWG, FWaaS), and SD-WAN into a single cloud-delivered platform. SASE provides a unified approach to securing remote access, cloud access, and internet access through a single policy framework:
Remote users connect to the SASE platform. The platform verifies identity and device posture (ZTNA). Internet-bound traffic is inspected for threats (Secure Web Gateway, DNS filtering). Cloud application access is governed by CASB policies (DLP, access control, activity monitoring). Private application access is brokered through ZTNA without VPN.
SASE platforms (Zscaler, Palo Alto Prisma SASE, Cisco Secure Access, Netskope, Cato Networks) provide a converged architecture that eliminates the need for separate VPN, web proxy, CASB, and firewall appliances. For organizations with a predominantly remote workforce and cloud-first infrastructure, SASE provides the most integrated security architecture.
Conditional access policies (Microsoft Entra Conditional Access, Okta Adaptive Access, Google BeyondCorp) enforce dynamic access decisions based on real-time context:
Signal inputs. User identity, group membership, device compliance status, location (IP-based or GPS), application being accessed, risk level (from identity protection signals), and session context.
Decision. Based on the signals, the policy grants access, blocks access, or requires additional verification (step-up MFA, device enrollment, terms-of-use acceptance).
Enforcement. The policy enforces the decision at the identity provider level, which cascades to every application federated through that identity provider. A single conditional access policy that blocks access from non-compliant devices applies to every application in the organization's SSO ecosystem.
Example policies: require MFA for all users accessing from outside the corporate network. Block access from devices that are not enrolled in Intune. Require phishing-resistant MFA for all access to financial applications regardless of location. Block access from countries where the organization has no operations. Require re-authentication every 4 hours for access to Restricted data.
Beyond the access technology, securing remote work requires additional controls:
Endpoint security. Remote endpoints must have the same security controls as on-premises endpoints: EDR, full-disk encryption, host-based firewall, automatic updates, and USB device control. MDM/UEM platforms enforce these controls regardless of the device's network location.
Split tunneling decisions. Full tunnel VPN routes all traffic through the corporate network (maximum control, maximum latency, maximum bandwidth consumption). Split tunnel VPN routes only corporate-destined traffic through the VPN (lower latency, lower bandwidth, but internet traffic bypasses corporate security controls). The choice involves trade-offs: full tunnel provides complete traffic inspection but degrades user experience. Split tunnel provides better performance but requires endpoint-level security controls (DNS filtering, web protection, DLP) that operate independently of the VPN.
Home network security. The organization does not control the user's home network: the router may have default credentials, the Wi-Fi may be shared with other household members, and other devices on the network may be compromised. VPN and ZTNA protect corporate traffic, but the endpoint remains exposed to the home network. Endpoint hardening, host-based firewalls, and network isolation between work and personal devices on the home network mitigate this risk.
The traditional security model assumed that users inside the network are trusted and users outside are not. Remote work dissolved this assumption: the majority of users are now outside the network most of the time. Security controls built around the network perimeter (firewalls, proxies, network-based IDS) do not protect users who bypass the perimeter entirely by connecting to cloud applications from personal devices on home networks.
Remote access security replaces the perimeter with identity: the user's verified identity and the device's verified posture become the trust boundary, not the network location.
Every remote access mechanism is an attack surface. VPN concentrators exposed to the internet are targeted by attackers: Ivanti Connect Secure, Fortinet FortiOS, Cisco ASA, and Citrix ADC have all had critical vulnerabilities exploited at scale. The Change Healthcare breach (2024) began with compromised credentials on a remote access portal without MFA. Remote access infrastructure must be hardened, patched, and monitored with the same intensity as any internet-facing service.
Remote access security is required by compliance frameworks. PCI DSS Requirement 8.3 mandates MFA for remote access to the cardholder data environment. NIST 800-171 requires multi-factor authentication for network access to privileged and non-privileged accounts. HIPAA requires access controls for remote access to systems containing ePHI. SOC 2 CC6.1 includes remote access in logical access controls. Auditors verify that remote access is authenticated (MFA), authorized (role-based), encrypted (VPN or ZTNA), and logged (session recording or activity monitoring).
Secure remote access sits primarily in the IAT (Identity Access and Trust) domain of the Planetary Defense Model, with SPH (endpoint posture) and VSD (attack surface) interactions. IAT owns the authentication and authorization architecture: how remote users prove their identity, how their access is scoped, and how their sessions are governed. SPH owns the endpoint posture: ensuring remote devices meet the same security standards as on-premises devices. VSD owns the attack surface: the remote access infrastructure (VPN concentrators, ZTNA connectors) is internet-facing and must be hardened and monitored.
CDA's Zero Possession Architecture (ZPA) methodology aligns with ZTNA principles. "Trust nothing. Possess nothing. Verify everything." VPN trusts the authenticated user with network access. ZTNA trusts nothing: every access request is verified for identity, device posture, and application authorization. ZPA applied to remote access means no standing network access, per-application authorization, continuous posture evaluation, and immediate revocation when conditions change.
Two TOP missions connect to remote access:
CDA approaches remote access with one priority: MFA on every remote access mechanism is non-negotiable. The Change Healthcare breach demonstrated the consequence of remote access without MFA at national scale. Every CDA assessment checks MFA enforcement on VPN, ZTNA, RDP, SSH, and every other remote access pathway. Missing MFA on remote access is a critical finding in every FRM report.
Word count: 1,942