Zero Trust Network Access (ZTNA)

In traditional enterprise networks, Virtual Private Network (VPN) solutions are implemented as a way of providing users access internal resources remotely. With the changes in the society after the COVID pandemic, an exponential number of users started working remotely, increasing the number of clients of that technology.

The problem with VPNs is that they follow the network security model called Castle and Moat. In this model, clients cannot access resources if they are not connected to the VPN, but once they are within the network, they have full access to the data and applications, even if they do not use it for its daily work. This model presents a vulnerability, since if an attacker gain access to the network, it can use it as an attack vector to run cyber attacks such as Man-in-the-middle (MITM) or ransomware.

Another common trend, is that many organisations are moving their workload to the Cloud. There is not a single 'castle' protect anymore. Therefore, protecting access to a single perimeter does not make sense in such environments.

The diverse chracteristics of devices has also become a challenge. With the increase of the use of BYOD devices to serve hybrid workforces, network and security administrators have to deal with a high number of unmanaged devices.

A Brief History of Zero Trust

The journey toward "Never Trust, Always Verify" was not an overnight shift but a decades-long evolution of cybersecurity philosophy.

1994: The Academic Seed The phrase "Zero Trust" was first coined by Stephen Paul Marsh in his doctoral thesis, "Formalising Trust as a Computational Concept." Rather than viewing trust as a binary (0 or 1), Marsh proposed a mathematical scale where "0" represented Zero Trust—a state where trust is neither assumed nor ignored but must be calculated.

2010: The Forrester Revolution John Kindervag, an analyst at Forrester Research, brought the concept into the mainstream by popularizing Zero Trust Network Architecture (ZTNA). He challenged the "Inside vs. Outside" status quo, arguing that the distinction between trusted and untrusted networks was a dangerous fallacy. His mantra was simple: all traffic, regardless of its origin, must be inspected, controlled, and logged.

2014: Google’s BeyondCorp Google provided the first real-world "proof of concept" by announcing BeyondCorp. This initiative moved nearly every Google employee to a perimeter-less model, proving that a global enterprise could function securely by shifting access controls from the network perimeter to individual users and devices.

2020: The NIST Standard (800-207) The National Institute of Standards and Technology (NIST) published SP 800-207, providing the official "blueprint" for Zero Trust. This document moved ZTA from a marketing buzzword to a formalized set of architectural standards and strategic components.

2021: The US Federal Mandate The concept reached the highest levels of government when Executive Order 14028 was issued. This mandate required federal agencies to adopt Zero Trust Architectures, signaling a definitive shift in how the world’s most targeted organizations must approach cybersecurity.

The Three Pillars of Zero Trust

The transition to a Zero Trust model is built upon three foundational security principles:

1. Least Privilege: Users are granted the minimum level of access - and only to the specific resources - required to perform their job.
2. Continuous Authentication and Authorization: Trust is never static. The system constantly re-verifies identity and permissions throughout the entire session.
3. Microsegmentation: The network is broken down into small, isolated zones to prevent "lateral movement," ensuring that if one area is compromised, the attacker cannot easily jump to another.

From Theory to Deployment: Key Components

To bring these concepts to life, ZTNA architectures rely on three critical architectural layers:

• The Identity Provider (IdP): This serves as the "source of truth" for who a user is (e.g., Microsoft Entra ID or Okta). For a robust Zero Trust posture, Multi-Factor Authentication (MFA) is a mandatory requirement here to mitigate the risk of stolen credentials.
• The Policy Engine (The "Brain"): This system—hosted on-premises or in the cloud—constantly analyzes telemetry data. It assesses the "health" of the endpoint in real-time, checking for vulnerabilities, missing patches, or suspicious behavior. It synchronizes with the IdP to ensure that the user’s security posture matches the required trust level.
• The Enforcement Gateway (The "Guard"): This is the physical or virtual gatekeeper that enforces the decisions made by the Policy Engine. It sits between the user and the application, verifying identity and device context before allowing a single packet of data to pass through.

The User Connection Flow

Understanding the user workflow is essential for administrators, as it shifts the security focus from "Who has the key to the front door?" to "Is this person - on this specific device - authorised to access this specific resource right now?"

1. The Access Request

When a user on a managed device attempts to access an internal application, the process begins with the Zero Trust client agent (or a browser-based gateway for agentless setups). This lightweight component serves as the bridge between the endpoint and the applications.

Unlike traditional VPNs that operate transparently at the network layer, the ZTNA client is active. It intercepts the request and establishes a secure "control plane" communication with a user management system deployed in the Cloud or on premises, before any data is allowed to flow.

2. Device and User Intelligence Gathering

Before access is granted, the system conducts a comprehensive "security audit" utilising the agent installed. The 'User Management System' receives a detailed profile containing two critical streams of data:

• User Identity: Verified via the Identity Provider (IdP), checking authentication status, MFA success, group memberships, and assigned roles.
• Device Posture (Telemetry): The client agent submits real-time health data, including:
• OS Integrity: Current version and patch levels.
• Endpoint Security: Status of antivirus/EDR (e.g., CrowdStrike, Microsoft Defender).
• System Configuration: Disk encryption status and firewall activation.
• Risk Indicators: Detection of known vulnerabilities or suspicious "jailbreak" indicators.

3. The Dynamic Trust Profile

The system utilises information from the telemetry and the IdP to map an unique trust profile for the user. As the agent is verifying the user authentication information, and its device security posture continously, this trust is temporary and context-bound.

For example, a "clean" corporate laptop connecting from a known office might receive a high trust profile, while the same user on a personal device from an untrusted public Wi-Fi would trigger a different profile - potentially limiting access to critical applications. This continuous assessment is a well-known characteristic of ZTNA, ensuring that trust is never assumed, but always earned.

Policy Enforcement: Vendor-Specific Approaches

While the foundational principles of ZTNA remain consistent across vendors, the actual enforcement of policies varies significantly in architecture. Understanding these differences is critical for deployment planning.

Centralized Enforcement Model

1. Fortinet

Fortinet implements ZTNA through a two-component system. The FortiClient EMS (Endpoint Management Server) serves as the central repository for all telemetry, receiving continuous information about device compliance and user activity. When a user connects, the FortiClient agent on their endpoint reports its security posture to EMS, which generates contextual tags reflecting the device's current state - for example, tags indicating "Windows-Defender-Active," "Critical-Patch-Missing," or "Suspicious-Activity-Detected."

These tags are synchronised from EMS to the FortiGate firewall, which typically sits at the network perimeter or closer to internal applications. The FortiGate then evaluates incoming access requests against ZTNA proxy policies that reference these tags. If the user and device meet the policy conditions, a proxy tunnel is established, and traffic flows through the FortiGate to the destination application. If conditions are not met - for instance, if endpoint protection is disabled or a critical vulnerability is detected - the FortiGate blocks access. 

This architecture means that the enforcement point (FortiGate) and the telemetry source (EMS) operate in concert, with the FortiGate serving as both the policy decision point and the traffic conduit.

Cloud-Native Brokered Architecture (Zscaler, HPE Aruba, Palo Alto Networks)

Unlike traditional firewall-based approaches, these three vendors utilize a Cloud-Native, Inside-Out model. In this architecture, the control plane (policy decision) is hosted in the cloud, while lightweight "connectors" sit inside the customer's environment to create outbound-only tunnels. This eliminates the need for inbound open ports and ensures users never directly access the network - only the specific application.

1. Zscaler

Zscaler’s architecture eliminates network perimeters by functioning as an intelligent switchboard in the cloud. When a user attempts access, the Zscaler Client Connector contacts the cloud platform directly. The Zscaler Policy Engine evaluates identity, device posture, and context (location, time) before brokering a connection.

If approved, the cloud creates an ephemeral microtunnel between the user and an App Connector - a lightweight virtual appliance sitting near the application. Critically, there is no direct network path between the client and the application; the Zscaler cloud proxies the connection, stitching the two tunnels together. If access is denied, the application remains invisible to the user.

2. HPE Aruba Networking (Axis)

HPE Aruba Networking delivers ZTNA through its SSE Platform (formerly Axis Security), a global cloud broker that handles all authentication and authorization. It operates on a similar principle to Zscaler but emphasizes its "Atmos" architecture.

Connectivity is handled by the SSE Connector, a virtual machine deployed in the customer's data center. This connector operates exclusively on an outbound model: it dials out to the HPE cloud on port 443, eliminating any inbound exposure. 

The connector acts purely as a conduit - it does not make policy decisions or assess identity locally. Instead, the SSE cloud acts as the "switch," brokering encrypted traffic between the authenticated user and the private app only after the cloud policy engine grants approval.

3. Palo Alto Networks

Palo Alto Networks implements a cloud-native Zero Trust Network Access model with Prisma Access, using a broker architecture and connector VMs that establish automated outbound tunnels to the service. These connectors are deployed close to private applications, keep internal IP space hidden, and provide secure paths for user-to-app traffic over IPSec.
​
Once connected, traffic is continuously inspected by Prisma Access security services, including intrusion and threat prevention, sandboxing via WildFire, and URL-based controls. Data loss prevention policies can be applied to the same flows to monitor and control sensitive information throughout the life of the session, not just at initial connection time.

Continuous Re-evaluation and Adaptive Policies

Across all vendor implementations, policy enforcement is not a one-time check at connection initiation. Throughout the session, the centralised system continuously monitors device posture and user behavior. If a vulnerability is discovered, malware detected, or unauthorised activity identified, the system can immediately revoke access or trigger adaptive responses - downgrading a user to read-only access, requiring additional authentication factors, or forcing disconnection and device remediation before reconnection is allowed.

This continuous evaluation fundamentally differs from VPN architectures, where a user connecting with a valid credential at 9 AM and still connected at 4 PM maintains identical access regardless of intervening security events.

Policy Logging and Visibility

A critical advantage of ZTNA is comprehensive visibility into all access attempts. Every connection request - whether approved or denied - is logged with complete context: user identity, device details, access timestamp, geographic location, application accessed, and the specific policy rule that governed the decision.

This logging infrastructure enables security teams to audit who accessed what, why they were granted (or denied) access, and to detect anomalous patterns such as a user suddenly accessing applications they've never accessed before from a geographic location inconsistent with their normal work patterns.

Conclusion: Beyond the Perimeter

The transition from traditional VPNs to Zero Trust Network Access (ZTNA) represents more than just a technical upgrade; it is a necessary evolution in response to a borderless digital world.

By shifting the focus from network location to identity and device context, ZTNA effectively eliminates the "implicit trust" that hackers have exploited for decades. Regardless of the choice of vendor the goal is still the same: Never Trust, Always Verify.