Secure Remote Access

# Secure Remote Access

Definition

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.

How It Works

VPN (Virtual Private Network)

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 (Zero Trust Network Access)

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 (Secure Access Service Edge)

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

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.

Remote Work Security Controls

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.

Why It Matters

The Perimeter Has Dissolved

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.

Attack Surface Expansion

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.

Compliance

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).

Related Articles

• Zero Trust Architecture
• Multi-Factor Authentication (MFA)
• Mobile Device Security
• Wireless Network Security
• Cloud Security
• Identity Access and Trust (IAT): Civilization

Sources

1. National Institute of Standards and Technology (NIST). "Zero Trust Architecture: SP 800-207." U.S. Department of Commerce, August 2020.
2. Gartner. "Market Guide for Zero Trust Network Access." Gartner, 2024.
3. Cybersecurity and Infrastructure Security Agency (CISA). "Secure Remote Access: Guidance for Organizations." CISA, 2024.
4. PCI Security Standards Council. "PCI DSS v4.0: Requirement 8.3 (Multi-Factor Authentication for Remote Access)." PCI SSC, March 2022.
5. National Institute of Standards and Technology (NIST). "Guide to Enterprise Telework, Remote Access, and BYOD Security: SP 800-46 Rev. 2." U.S. Department of Commerce, 2016 (principles remain applicable).

Word count: 1,942