Zero Trust Network Access: An Introduction

Originally, this post was intended to focus on the deployment of Microsoft Global Secure Access. However, as I began writing, it became clear that a proper introduction to the concept of Zero Trust Network Access (ZTNA) was required to set the stage. As such, I’ve decided to begin with this foundational overview, followed by dedicated posts exploring the approaches taken by both Microsoft and Cloudflare in delivering ZTNA solutions.

The History of VPN

For those unfamiliar with the concept of Zero Trust Network Access (ZTNA), a common question might be: “What are the tangible benefits for me?” To understand the value ZTNA brings, it's important to first look at how remote access has traditionally been handled through Virtual Private Networks (VPNs).

The origins of VPN technology date back to the mid-1990s with the introduction of the Point-to-Point Tunnelling Protocol (PPTP). As business needs evolved and the demand for stronger security grew, VPN technologies also progressed. This included the development of more robust protocols and encryption standards, better authentication mechanisms, and support for increasingly complex enterprise architectures.

How 'Traditional VPNs' Work

Traditional VPNs operate by creating a secure, encrypted tunnel between a user’s device and a private network, usually the corporate network. Once a connection is established, the user is effectively “on the network”, with broad access to internal resources, applications, and systems, often beyond what is strictly necessary for their role.

This model assumes a level of inherent trust: if a user can authenticate and establish a VPN connection, they are granted significant access by default. While encryption protects data in transit, the underlying access model poses several challenges, especially in modern environments where users, devices, and applications are no longer confined within a single, secure perimeter.

Some key characteristics of traditional VPNs include:

• Perimeter-based security – Trust is established at the network boundary.
• Overprivileged access – Once connected, users often gain access to large portions of the internal network.
• Device trust assumptions – VPNs typically trust the device once credentials are provided, with limited visibility into device health or posture.
• Network-level access – VPNs operate at the network layer, which can be difficult to segment or restrict granularly.

While VPNs have served organisations well for decades, these characteristics also introduce risk; especially in a world of hybrid work, bring-your-own-device (BYOD) policies, and cloud-native applications.

From a network engineering perspective, the rise of hybrid environments, spanning on-premises infrastructure and multiple cloud platforms, has introduced significant complexity. Managing firewall rules, routing configurations, and access control across these disparate environments has become increasingly difficult.

Traditional network architectures, designed around a centralised perimeter, are increasingly ill-suited to today’s fragmented IT environments. As organisations adopt hybrid models spanning on-premises infrastructure and multiple cloud platforms, enforcing consistent network segmentation and access control becomes both time-consuming and error-prone. Whether managing restrictions over VPN tunnels or attempting to control east-west traffic within the internal network, the complexity grows exponentially with scale and diversity.

Moreover, traditional VPNs typically rely on a hub-and-spoke architecture, where all user traffic is backhauled through a central data centre or headquarters. While this approach can simplify routing and centralised security enforcement, it introduces significant latency and performance challenges, especially for remote users located far from the ‘hub’. These issues are particularly noticeable when using bandwidth-intensive applications such as cloud-based file sharing, video conferencing, or real-time collaboration tools. The greater the distance from the central hub, the more degraded the user experience becomes.

This has highlighted the limitations of legacy network security models and reinforced the need for a more dynamic, context-aware approach to access control aka Zero Trust Network Access.

Zero Trust Network Access

Zero Trust Network Access (ZTNA) represents a modern approach to secure remote and internal access. At its core, Zero Trust operates on the principle of never trust, always verify, regardless of whether a user is inside or outside the network perimeter.

Unlike traditional VPNs that grant broad network-level access once a connection is established, ZTNA enforces strict, identity and context-based access controls. Access is granted only to specific applications or services based on who the user is, the health of their device, their location, and other contextual signals. There is no inherent trust in the network itself, each request is treated as potentially hostile until proven otherwise.

By decoupling access from the underlying network, ZTNA also simplifies network management, reducing the reliance on complex firewall rules, segmented VLANs, and backhauled traffic flows.

This model allows organisations to reduce their attack surface, minimise lateral movement within the network, and improve visibility and control over who is accessing what. With applications now spread across on-premise data centres, public cloud environments, and SaaS platforms, ZTNA provides a scalable, adaptable solution that aligns with the demands of modern enterprise architecture and the realities of a distributed workforce.

How It Works in Practice

To bring this to life, the following example illustrates how Zero Trust Network Access (ZTNA) can both enhance security and simplify network management. For the purposes of this scenario, we’ll use a fictional (and undoubtedly innovative) organisation called Nsayeed.

Nsayeed operates an inter-connected hybrid environment spanning both on-premises infrastructure and public cloud. Each zone, whether on-premise or within Azure, has its own perimeter firewall managing inbound and outbound traffic. Additionally, network traffic to cloud-hosted applications are further controlled using Network Security Groups (NSGs).

Internet-bound traffic is routed through the on-premises environment, where proxies enforce web filtering and logging.

Traditional VPN

The following diagram provides an overview of the networking approach using a 'traditional always on VPN'

Summary of Diagram

The diagram above illustrates how a user connects to resources across a hybrid environment (on-premises, Azure, and AWS) using a centralised, VPN-based architecture.

The User Endpoint connects via the internet to establish a connection with the VPN Server:

• The External Firewall at NSayeed HQ allows inbound access to the VPN server from the VPN client. Since users may connect from anywhere, an inbound rule must be configured to allow traffic from any location (or restricted IP ranges if geo-filtering is in place).
• The VPN Server authenticates the user and establishes a secure tunnel.
• Once connected, traffic passes through the Internal Firewall, where specific rules allow communication from the VPN server subnet.
• Outbound traffic to the internet is routed via proxy servers

From here, traffic is routed via the Core Router to access various resources:

• Internal On-Prem Resources
• Cloud-hosted resources:
  • Azure: Routed via ExpressRoute, through the Azure Perimeter Firewall (with a rule to allow traffic from the VPN server subnet), then through a Network Security Group with the appropriate rule, and finally to Application 2.
  • AWS: Routed via AWS Direct Connect, through the AWS Perimeter Firewall (also with a rule to allow traffic from the VPN server), then through a Security Group, and finally to Application 1.

The following are key challenges/risks presented by this approach:

• Increased Attack Surface - VPNs create an additional entry point into the corporate network. Since VPNs are often targeted by attackers due to their access capabilities, securing the VPN gateway becomes a critical task. There have been a number of vulnerabilities in well known vendor offerings, below are some examples I have come across in a quick google search:
  • Ivanti Connect Secure VPN Targeted in New Zero-Day Exploitation
  • SonicOS SSL VPN Authentication Bypass Vulnerability (CVE-2024-53704)
  • FortiOS SSL VPN Vulnerability Actively Exploited in the Wild
• Complex Firewall Rule Management - To enable an end user to access application 1 hosted in the cloud several rules have to be created in different firewalls (depending on how your network segmented):
  • On-Premise perimeter firewall to allow inbound access to the VPN server from user endpoints.
• Inbound rule on the cloud perimeter firewall to allow traffic from the VPN server subnet.
• Inbound rule on the network security group to allow traffic to the application from the VPN subnet.
• Over-Privileged Access: Once a VPN connection is established, users often gain broad network-level access, which may exceed their needs. This can create significant security risks, as malicious actors or compromised devices can move laterally within the network.
• Endpoint Security Risks: VPNs generally trust the device once it has authenticated, without verifying the health or security posture of the device beyond the initial authentication.
• Scalability Issues: As the number of remote users increases or the organisation expands its infrastructure, VPNs often struggle to scale effectively. Adding more users can require more VPN servers or more complex network configurations.
• Latency and Performance Bottlenecks: As noted earlier, routing all traffic through a centralised data centre or VPN gateway introduces latency, particularly for users far from the corporate hub.

Zero Trust Network Access

The following diagram provides an overview of the networking approach using a ZTNA approach.

In a ZTNA setup, similar to traditional VPNs, appliances are still required to enable connectivity. However, where ZTNA differs is in the strategic placement of these appliances. Rather than relying on a centralised VPN server or gateway, ZTNA appliances can be situated closer to the source of the applications that users need to access. These appliances then establish an outbound connection to a Secure Web Gateway (SWG), which acts as an intermediary between the user and the application. This architecture allows for more granular, context-aware access control, as well as improved performance by reducing the need for backhauling traffic through a centralised hub.

In the ZTNA architecture:

• The User Endpoint initiates an outbound connection directly to the Secure Web Gateway (SWG), managed by the ZTNA vendor.
• Each environment (NSayeed HQ, Azure, AWS) has a dedicated ZTNA Appliance. These appliances also establish outbound connections to the SWG. Because these connections are initiated from within the organisation, there's reduced need for inbound firewall rules (only to allow appliances to communicate with applications e.g. configuring security groups).
• Before granting access, the SWG validates the user's identity + other contextual information through an external Identity Provider (e.g., Entra ID), which confirms the user's credentials and optionally their device security posture.
• Once authenticated, the SWG brokers secure access for the user to authorised resources:
  • Internal On-Premises Resources
  • Cloud-Hosted Applications in Azure and AWS, where internal firewalls, Network Security Groups (NSGs), and security groups further enforce granular access controls.
• Internet bound traffic is routed via the Secure Web Gateway.

In this model, users are only granted access to specific applications based on their identity, device health, location, and other contextual factors. This reduces the overall attack surface by limiting access to just the applications that users need, as opposed to providing broad network-level access. Additionally, because the traffic is securely routed through the SWG, it can be monitored and filtered for potential threats, improving both security and performance.

Lets have a look at how ZTNA addresses the challenges I raised around a traditional VPN approach:

How ZTNA Addresses Common VPN Challenges

• Complex Firewall Rule Management & Routing: With ZTNA, this complexity is reduced. The appliances responsible for ZTNA are placed closer to the applications users need to access, and the traffic is routed through a Secure Web Gateway (SWG), which centralises routing and policy enforcement.
• Over-Privileged Access: ZTNA mitigates this risk by enforcing least privilege access. Instead of granting access to the entire network or large subnets, users only granted access to specific applications they are authorised to use, based on their identity and context (e.g., device health, location).
• Reduced Attack Surface: ZTNA addresses this by communicated with the SWG via an outbound connection, so inbound ports don't have to be opened. Note this does not remove the attack surface entirely as the appliances are still susceptible to insider or supply chain attacks.
• Scalability Issues: ZTNA simplifies scalability by removing the need for centralised VPN servers. Instead, access is managed via distributed appliances that communicate directly with the Secure Web Gateway.
• Latency and Performance Bottlenecks: ZTNA eliminates this issue by enabling direct, outbound connections from the user to the application via a Secure Web Gateway managed by the ZTNA vendor. These gateways are typically part of a highly distributed, global infrastructure, allowing user traffic to be routed through the nearest access point. This significantly reduces latency and improves performance, particularly for remote users and bandwidth-intensive applications.

Secure Web Gateway

I've mentioned the 'Secure Web Gateway' (SWG) several times, but what exactly does this component do within a Zero Trust architecture? While specific features may vary across different vendors, common capabilities typically include:

Identity Integration and Authentication

• Integrates with Identity Providers (e.g., Microsoft Entra ID, Okta) to enforce authentication and identity-driven access policies.

Device Posture Enforcement

• Evaluates and enforces endpoint security standards, verifying devices meet organisational compliance requirements (antivirus, encryption status, OS patches, etc.).

Contextual Access Control

• Applies adaptive, risk-based access policies depending on the user's identity, role, device health, geographic location, and behaviour patterns.

TLS Inspection and Decryption

• Performs secure inspection of encrypted (HTTPS/TLS) traffic, enabling detailed threat analysis, data loss prevention (DLP), and application control while preserving end-to-end encryption outside the inspection point.

Real-Time Threat Protection

• Provides inline threat detection capabilities, such as malware analysis and behavioural analytics.

Data Loss Prevention (DLP)

• Implements DLP policies that monitor sensitive data flows, preventing accidental or intentional data exfiltration across web traffic.

Logging and Visibility

• Generates audit logs, giving security teams real-time visibility into user activity, policy enforcement, and potential security incidents.

URL Filtering and Content Control

• Enables policy-based web filtering to restrict access to malicious, inappropriate, or unauthorised websites.

Highly Available Global Infrastructure

• Operates through a geographically distributed infrastructure to reduce latency, improve performance, and provide consistent, secure user experiences globally.

Conclusion

While a Zero Trust Network Access (ZTNA) approach offers significantly enhanced security and flexibility compared to traditional VPNs, it is not a silver bullet. Security risks are not eliminated entirely. You will still be responsible for maintaining and patching the ZTNA appliances and client connectors within your environment, and your overall risk posture is also influenced by the controls and resilience of the vendor’s infrastructure, particularly the Secure Web Gateway (SWG).

As you plan your migration to ZTNA, it’s important to evaluate not just the technical benefits, but also the operational and governance implications. Ensure that your third-party risk management approach includes due diligence on the ZTNA vendor’s security practices, availability guarantees, and incident response processes.

If you have any questions, comments or something needs to be amended in this post please comment below (members only) or reach out to me on one of the links in my contact page.