Zero Trust Network Access (ZTNA)
VPN Was Built for a World That No Longer Exists. ZTNA Was Built for the One You’re Actually Operating In.
Virtual Private Networks — VPNs — were designed to solve a specific problem: giving remote employees access to corporate network resources as if they were physically in the office. They solved that problem reasonably well for two decades when most applications lived on servers in corporate data centers, most employees worked from company-managed offices, and the network perimeter was a coherent security boundary that meant something.
None of those conditions still apply for most organizations. Applications live in Microsoft 365, AWS, Salesforce, and dozens of other cloud platforms. Employees work from home, hotels, client sites, and coffee shops on a mix of corporate and personal devices. Contractors and vendors need access to specific systems from networks and devices that the IT team has never managed. And the attackers targeting your organization know that VPN — which places authenticated remote users directly on the corporate network with broad lateral movement capability — is one of the most valuable attack surfaces available to them. VPN concentrators are among the most targeted enterprise systems for initial access, and a compromised VPN credential gives an attacker the same network access as a legitimate remote employee — which is far more access than any single user needs to do their job.
Zero Trust Network Access (ZTNA) replaces VPN’s network-centric access model with an identity and application-centric model — granting authenticated users access to specific applications they need, not network access to everything those applications happen to sit on. The corporate network is never exposed to the remote device. Lateral movement from a compromised ZTNA session is structurally prevented by the architecture rather than detected after the fact.
Lionhive designs and implements ZTNA architectures that replace legacy VPN for remote access, extend Zero Trust principles to application access for all users regardless of location, and integrate with the broader Zero Trust Architecture framework aligned with NIST SP 800-207 and the CISA Zero Trust Maturity Model v2.0.
VPN tells the network to trust a user because they authenticated. ZTNA tells each application to verify a user before granting access — every time, regardless of where the request originates, and only for the specific application being requested. The difference in security posture between those two models is the difference between locking the front door and giving everyone who has a key access to every room in the building versus requiring each person to verify their identity at each door they want to open.
The Problems With VPN That ZTNA Solves
Excessive Network Access
Traditional VPN places the remote user on the corporate network — which means a sales representative working from home has the same network-level access as a server administrator in the data center, because both are “on the network.” The principle of least privilege — granting access to only what is needed — is structurally impossible to enforce with VPN because VPN doesn’t grant access to specific resources. It grants access to the network those resources happen to sit on. ZTNA grants access to specific applications and services — the sales representative gets access to the CRM and email. The server administrator gets access to the management infrastructure. Neither can reach what the other can reach, regardless of credential.
Lateral Movement After Compromise
When a VPN credential is compromised — through phishing, credential stuffing, or malware on a remote endpoint — the attacker inherits the same network access as the legitimate user. From that network access, lateral movement to other systems, data stores, and infrastructure is straightforward in environments without additional network segmentation controls. ZTNA eliminates this attack path structurally — a compromised ZTNA session grants access only to the specific applications the session was authorized for, with no network-level connectivity to anything else. An attacker who compromises a ZTNA session for a marketing employee’s CRM access cannot use that session to reach financial systems, HR data, or infrastructure management tools.
VPN as an Attack Surface
VPN concentrators — the network appliances that terminate VPN connections — are among the most actively exploited enterprise systems. CISA’s Known Exploited Vulnerabilities catalog consistently includes critical vulnerabilities in VPN products from major vendors including Ivanti, Fortinet, Cisco, and Pulse Secure — vulnerabilities that allow pre-authentication remote code execution, credential theft, and network access without requiring a valid user credential at all. Organizations running unpatched VPN concentrators are operating with known, actively exploited attack surface. ZTNA eliminates the VPN concentrator from the architecture — there is no network appliance exposed to the internet accepting inbound connections, because ZTNA brokers outbound connections from the application to authenticated users rather than accepting inbound connections from remote devices to the network.
Performance and User Experience
VPN hairpinning — routing all remote traffic through the corporate network before it reaches cloud applications — creates performance degradation that affects user productivity and drives shadow IT adoption as employees find workarounds for slow corporate systems. A remote employee in Dallas accessing Microsoft 365 through a VPN tunnel that routes traffic through a corporate data center in New Jersey before reaching Microsoft’s cloud is adding unnecessary latency to every interaction. ZTNA provides direct, optimized connectivity between the user and the application — without routing through a corporate bottleneck — improving performance for cloud application access while maintaining security controls.
Unmanaged Device Risk
VPN typically extends network access to any device that can authenticate with a valid credential — including personal devices that have never been managed, patched, or evaluated for security compliance. A contractor working from a personal laptop with outdated software, no endpoint protection, and unknown security posture gets the same network access through VPN as a corporate-managed device with current patches and EDR deployed. ZTNA integrates device trust evaluation into access decisions — requiring devices to meet defined compliance criteria before access is granted, and enforcing different access policies for managed versus unmanaged devices accessing the same applications.
How ZTNA Works
ZTNA operates through a broker architecture that sits between users and applications — evaluating identity and device trust before establishing application-specific connectivity, without exposing the application or the network it sits on to the remote device or the internet.
When a user attempts to access an application through ZTNA:
1. Identity Verification — The user authenticates to the identity provider — Microsoft Entra ID or Okta — with MFA enforced. Conditional access policies evaluate the risk context of the authentication — user identity, device compliance status, location, and real-time risk signals — before issuing an access token.
2. Device Trust Evaluation — The ZTNA client on the device reports device compliance status — patch level, endpoint protection presence, disk encryption status, and managed device enrollment — to the ZTNA broker. Non-compliant devices are denied access or restricted to limited access environments depending on the policy for the requested application.
3. Application-Specific Tunnel — The ZTNA broker establishes an encrypted, application-specific tunnel between the authenticated user on the verified device and the requested application — without placing the device on the network, without exposing the application to inbound internet connections, and without granting any network access beyond the specific application tunnel established for this session.
4. Continuous Verification — Unlike VPN sessions that are trusted for the duration of the connection once authenticated, ZTNA continuously evaluates session risk — monitoring for changes in device compliance, anomalous access patterns, or elevated risk signals — and can terminate or restrict sessions that deviate from expected behavior without terminating other active sessions.
5. Session Logging and Monitoring — Every ZTNA session is logged — user identity, device, application accessed, data accessed within the application, session duration, and any anomalies detected — providing the audit trail that compliance frameworks require and that security monitoring integrates for threat detection.
ZTNA Implementation Approaches
ZTNA is implemented through two primary architectural approaches — each appropriate for different organizational contexts and existing infrastructure investments:
Agent-Based ZTNA
Agent-based ZTNA deploys a lightweight client on managed devices that communicates with the ZTNA broker, reports device compliance status, and establishes application-specific tunnels when access is requested. Agent-based ZTNA provides the most comprehensive device trust evaluation and the most granular access control — because the agent has visibility into device health, can enforce compliance requirements, and can be integrated deeply with endpoint security tooling including CrowdStrike and SentinelOne to use endpoint security posture as a real-time access signal.
Agent-based ZTNA is appropriate for corporate-managed devices and for organizations transitioning from VPN where the endpoint is known and controllable. Lionhive implements agent-based ZTNA through leading platforms integrated with the Microsoft Entra ID and Okta identity layer — providing consistent access policy enforcement across on-premises applications, private cloud workloads, and the public cloud environments that make up the modern application estate.
Agentless ZTNA
Agentless ZTNA provides browser-based access to applications without requiring a client installed on the device — making it appropriate for contractor and third-party access scenarios where device management is not possible, and for BYOD policies where personal device management raises privacy concerns. Agentless ZTNA trades some depth of device trust evaluation for broader applicability — the access policy can verify identity and apply conditional access rules but has limited visibility into the unmanaged device’s security posture.
Lionhive implements agentless ZTNA for third-party access use cases — contractors, vendors, and partners who need specific application access without network connectivity or managed device requirements — alongside agent-based ZTNA for corporate employees, creating a unified access architecture with differentiated policies based on user type and device management status.
ZTNA for On-Premises Applications
One of the most common misconceptions about ZTNA is that it only applies to cloud applications. ZTNA is equally effective — and often more impactful — for on-premises applications that currently rely on VPN for remote access. A ZTNA connector deployed in the on-premises environment establishes an outbound connection to the ZTNA cloud broker — eliminating inbound firewall rules for remote access, removing the VPN concentrator from the attack surface, and applying identity and device trust controls to access that VPN provides without them. On-premises applications that require remote access — ERP systems, manufacturing control systems, legacy applications that can’t be moved to the cloud — benefit from ZTNA’s security model as much as cloud applications do.
ZTNA and Regulatory Compliance
ZTNA satisfies the remote access security requirements of the major frameworks and regulations governing US organizations — replacing the weaker controls that VPN provides with the documented, auditable, identity-verified access control that compliance frameworks require:
NIST CSF 2.0 and NIST SP 800-207 — ZTNA implements the Zero Trust architectural tenets defined in NIST SP 800-207 — verifying all access requests regardless of network location, enforcing least-privilege access, and logging all access for monitoring. ZTNA is the Networks pillar implementation in the CISA Zero Trust Maturity Model v2.0.
HIPAA Security Rule — Remote access to systems containing electronic protected health information must be controlled and audited. ZTNA’s application-specific access, continuous verification, and comprehensive session logging satisfies HIPAA’s access control and audit control requirements for remote access to clinical and administrative systems handling PHI.
SOC 2 Type II — The CC6 Logical Access Controls criteria require that access to systems is restricted based on authorized access. ZTNA’s identity-verified, application-specific access model with device trust evaluation satisfies SOC 2 remote access control requirements more completely than VPN.
NY DFS 23 NYCRR 500 — Section 500.07 requires access controls limiting access privileges to what is necessary and sufficient. ZTNA’s least-privilege application access directly satisfies this requirement for remote access scenarios.
CMMC 2.0 — Access Control practices AC.2.005 (limiting system access to authorized users) and AC.2.006 (limiting system access to authorized transactions and functions) are directly satisfied by ZTNA’s application-specific access model for defense contractor remote access to CUI systems.
FINRA Cybersecurity — FINRA’s cybersecurity guidance emphasizes access controls for systems containing client financial data. ZTNA provides the documented, identity-verified remote access controls that FINRA examiners evaluate in cybersecurity examinations.
ZTNA Migration — Moving From VPN
Replacing VPN with ZTNA is typically a phased migration rather than a cutover — because VPN provides access to applications that must be catalogued, mapped, and transitioned to ZTNA access policies before VPN can be retired for each application. Lionhive manages ZTNA migrations through a structured approach:
Application Discovery and Cataloguing — Identifying every application currently accessed through VPN, its user population, its sensitivity classification, and its appropriate ZTNA access policy. Applications that appear to require broad network access through VPN often reveal, on examination, that they only need connectivity to specific ports and protocols — which ZTNA can provide with tighter controls than VPN allows.
Phased Application Migration — Transitioning applications from VPN to ZTNA in priority order — cloud applications first (which benefit most from eliminating hairpinning), then on-premises applications with defined remote access requirements, then legacy applications requiring custom connector configuration. VPN remains available for applications not yet migrated, with a defined timeline for full VPN retirement.
User Adoption and Training — The ZTNA client and access experience differs from VPN in ways that require user communication — setting expectations about what changes (no network tunnel, no IP address assignment, application-specific access), what stays the same (authenticated access to the applications they use), and how to handle scenarios where access is denied due to device compliance failures.
VPN Retirement — Decommissioning VPN concentrators once all applications have been migrated — removing the attack surface, eliminating the management overhead of VPN infrastructure, and completing the transition to a network architecture where the corporate network is not exposed to remote devices.
🌐 Why Organizations Choose Lionhive for ZTNA
- ZTNA architecture aligned with NIST SP 800-207 and CISA Zero Trust Maturity Model v2.0
- Agent-based ZTNA for corporate-managed devices integrated with CrowdStrike and SentinelOne device trust
- Agentless ZTNA for contractor and third-party access without managed device requirements
- Identity integration with Microsoft Entra ID and Okta — conditional access policies applied to every ZTNA session
- On-premises application ZTNA — eliminating VPN for legacy and private application remote access
- Phased VPN migration with structured application discovery, policy design, and retirement planning
- Regulatory alignment across HIPAA, SOC 2, NIST CSF, NY DFS, CMMC, and FINRA
- Integration with Managed SOC for ZTNA session monitoring and anomalous access detection
📞 Ready to Replace a Network Security Model Built for 2005 With One Built for 2026?
Most organizations running VPN know its limitations — the performance complaints, the security concerns, the lateral movement risk, the VPN concentrator vulnerabilities that make headlines every few months. The question is usually not whether ZTNA is the right direction but where to start and how to migrate without disrupting the remote access that the business depends on. Lionhive starts with an honest assessment of the current VPN architecture and the applications it provides access to — and builds the ZTNA migration roadmap that gets you from where you are to where you need to be on a timeline that the business can absorb. Let’s talk about what your remote access architecture should look like.
Part of Lionhive’s Cybersecurity & Compliance practice — see also Zero Trust Architecture, Identity & Access Management, Managed SOC, NIST CSF, and Vulnerability Management.