Zero Trust Network Access (ZTNA) Deployment: Architecture, Identity-Aware Proxy, and VPN Replacement Strategy
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Implemented ZTNA for a 300-person engineering organization that had been using a shared IPSec VPN where all 300 engineers had access to the same network segment — which included production database servers, internal admin panels, and the corporate code signing infrastructure. The VPN network ACLs were supposed to restrict access, but they had accumulated 400 rules over six years and nobody had the documentation to understand what they permitted anymore.
The ZTNA migration took four months and replaced the opaque firewall rule set with explicit application policies for each of 47 internal applications. Each policy stated exactly which IdP groups could access the application and what device posture was required. On the day VPN was deprecated, the access control posture went from 400 undocumented firewall rules to 47 documented application policies with explicit group membership requirements. Three developers who had VPN access but were not in any of the 47 application policies had their access removed — they had been on VPN for over a year with no application need, their VPN credentials simply never expired.
Architecture decisions: cloud-delivered versus on-premises ZTNA
The ZTNA architecture decision between cloud-delivered (Cloudflare Access, Zscaler Private Access, Netskope) and on-premises software-defined perimeter (OpenZiti, HashiCorp Boundary) determines the operational model, failure modes, and data sovereignty posture of the access control system. Cloud-delivered ZTNA shifts operational responsibility to the vendor, provides global PoP performance, and integrates with cloud-native IdPs without additional infrastructure. On-premises ZTNA maintains full control over access logs and authentication data, avoids vendor lock-in, and is suitable for air-gapped or high-security environments where cloud dependencies are prohibited.
Choose cloud-delivered ZTNA for organizations without dedicated network security engineering capacity
Cloud-delivered ZTNA products (Cloudflare Access, Zscaler Private Access, Google BeyondCorp Enterprise) are the appropriate choice for organizations that cannot staff dedicated network security engineers to operate an on-premises ZTNA platform. The operational model is similar to SaaS application administration: configure policies through a web console, integrate with the existing IdP via SAML or OIDC, deploy lightweight connectors in the private network for application tunneling, and deploy endpoint agents for device posture collection. The vendor operates the ZTNA edge, handles certificate management, and provides 99.9%+ availability SLAs. The tradeoff is that all access logs pass through the vendor's cloud infrastructure — an acceptable tradeoff for most organizations, but one that requires review of the vendor's data processing agreement for compliance requirements. Cloud-delivered ZTNA deployment for 300 users with 50 applications typically completes in 6-12 weeks with a two-person team, compared to 6-12 months for an on-premises deployment.
Implement HashiCorp Boundary for privileged access management to infrastructure components in air-gapped or regulated environments
Deploy HashiCorp Boundary as the ZTNA solution for privileged infrastructure access (SSH to servers, database access, Kubernetes API access) in environments where cloud-delivered ZTNA is prohibited by data residency requirements or network security policy. Boundary operates a controller (manages policies, targets, and users via API and UI) and workers (deployed in private networks to proxy connections to targets). Deploy the controller in a DMZ-accessible location and workers in each private network segment containing infrastructure targets. Configure targets for each type of infrastructure access: SSH targets referencing server host sets, database targets referencing database host sets, and Kubernetes targets referencing cluster endpoints. Connect Boundary to the organization's IdP using OIDC authentication so that Boundary user access is governed by the same IdP group memberships as other ZTNA applications. Boundary's session recording capability provides forensic audit trails of privileged sessions — SSH sessions and database queries executed through Boundary are recorded and stored for compliance review, a capability that VPN plus traditional SSH provides no equivalent of.
Operational transition: running ZTNA alongside VPN during migration
Running ZTNA alongside VPN during the migration period requires careful sequencing to ensure that each application moved to ZTNA is verified functional before VPN access to that application's network segment is restricted. Moving too fast — restricting VPN access before ZTNA access is confirmed working — causes user-impacting outages. Moving too slow — leaving VPN access open indefinitely after ZTNA is deployed — eliminates the security benefit of ZTNA since users can bypass ZTNA by using VPN.
Run a ZTNA pilot with the security and IT teams for 30 days before migrating any other users
Run a ZTNA pilot with the security team and IT administrators for 30 days before migrating any production users, using the pilot period to identify all application access issues, device posture configuration problems, and IdP integration issues in a low-impact environment. During the pilot, deploy ZTNA for a subset of the internal applications that the security and IT teams use daily, keep VPN active for all pilot participants, and gather feedback on user experience issues (application load time, authentication frequency, device posture check failures). Common issues found during pilot phases: applications that use WebSocket connections require specific ZTNA configuration for long-lived connections, applications that embed internal IP addresses in their responses require ZTNA split tunnel configuration, and device posture checks that reference OS certificate stores require cloudflared agent updates on macOS to handle keychain access permissions. Address all pilot-identified issues before expanding to the general user population — the security and IT teams can tolerate access issues and know how to escalate them, while the general user population generates support tickets and executive escalations for the same issues.
Create application-specific ZTNA acceptance tests that run before and after each migration batch
Create acceptance tests for each application before migrating it to ZTNA, and run those tests through the ZTNA path before removing VPN access to the application's network segment. An acceptance test for a web application includes: the login flow completes successfully through the ZTNA proxy, the application's main feature set is accessible without errors, file uploads and downloads work correctly through the proxy, any webhook or callback functionality that requires the ZTNA proxy to pass the correct client IP is verified, and application performance (page load time, API response time) is within 20% of VPN baseline. Document the acceptance test results for each application as evidence that the ZTNA migration was validated before VPN access was removed. For applications where acceptance testing reveals ZTNA-incompatible behavior (some legacy applications break when headers are modified by the proxy, or when the source IP changes), document these as exceptions requiring custom ZTNA configuration or delaying migration until the application can be updated.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
Zero Trust Network Access replaces the network-perimeter trust model with per-application, per-request identity and device verification that limits the blast radius of compromised credentials to only explicitly authorized applications rather than entire network segments. Choose cloud-delivered ZTNA for most organizations; deploy HashiCorp Boundary for privileged infrastructure access in regulated environments requiring on-premises control. Deploy application connectors to expose internal applications without opening inbound firewall rules. Configure device posture verification integrated with Intune or CrowdStrike as a required access condition alongside identity verification. Plan migration in application categories (web applications first, then infrastructure access) with 30-day pilot periods and application-specific acceptance tests before each VPN access restriction. Map access policies to IdP groups so that onboarding and offboarding automatically grant and revoke ZTNA access without per-user policy management. Measure security improvement through blast radius reduction, policy granularity comparison, and time-to-revoke metrics.
Frequently asked questions
What is the difference between ZTNA and VPN and why does it matter for security?
The fundamental difference between ZTNA and VPN is the granularity of access: VPN grants network-level access to a subnet or range of IP addresses, while ZTNA grants application-level access to specific resources for specific users based on identity and device verification at every connection. With VPN, a user who connects to the corporate network can initiate connections to any server, port, and service within the VPN network segment, limited only by internal firewall rules that are typically minimal for usability. With ZTNA, a user can connect to only the specific applications they are explicitly authorized to access — an application-level access policy that is enforced by the identity-aware proxy for every request, not just at connection establishment. The security implication is significant: a compromised VPN credential gives an attacker the same network-level access as the legitimate user, enabling lateral movement across all VPN-accessible systems. A compromised ZTNA user identity gives the attacker access only to the specific applications authorized for that user, with every access attempt logged and device posture re-evaluated. An attacker who compromises a developer's ZTNA identity can access the developer's authorized applications (code repositories, development environments, internal documentation) but cannot reach production databases, payment systems, or other infrastructure the developer's ZTNA policy does not include.
How do I set up Cloudflare Access as an identity-aware proxy for internal applications?
Set up Cloudflare Access to protect an internal application by routing access through Cloudflare's edge network with identity verification before the connection reaches the application server. Install a Cloudflare Tunnel connector (cloudflared) in the network hosting the internal application: download cloudflared, run cloudflared tunnel create my-tunnel to create a named tunnel, and configure the tunnel with the application's internal address: url: http://internal-app.local:8080. The cloudflared connector establishes an outbound connection to Cloudflare's edge without requiring inbound firewall rule changes — the application server is not directly accessible from the internet. In the Cloudflare Zero Trust dashboard, create an Access Application pointing to the tunnel's public hostname (app.yourdomain.com), configure the identity provider integration (Okta, Azure AD, or GitHub for identity verification), and create an Access Policy with an Include rule for the allowed users or groups. When a user navigates to app.yourdomain.com, Cloudflare redirects them to the identity provider for authentication, verifies the access policy, and proxies the connection to the internal application only if the policy allows. The application server's internal IP address is never exposed to the user or the internet — all connections originate from Cloudflare's network through the cloudflared tunnel.
How do I configure device posture verification in ZTNA to prevent access from non-compliant devices?
Configure device posture verification by integrating the ZTNA platform with your endpoint management system (Intune, Jamf, CrowdStrike) and adding device compliance as a required condition in access policies. In Cloudflare Access, add device posture integration under Settings > WARP Client > Device Posture, selecting the integration type (Microsoft Endpoint Manager, Crowdstrike, Jamf) and configuring the API credentials. Create device posture checks for each compliance requirement: OS Version (minimum macOS 14 or Windows 11), Disk Encryption (FileVault or BitLocker enabled), Firewall (host firewall enabled), and Client Certificate (a certificate issued by the corporate CA). In the Access Policy, add a Require condition for device compliance: the policy now requires both identity verification (user is in the Engineering group) AND device compliance (device has the corporate certificate and is managed by Intune). A user who is in the Engineering group but is accessing from a personal unmanaged laptop fails the device posture check and cannot access the application regardless of correct identity verification. Device posture signals are re-evaluated on each new connection through the ZTNA agent, so a device that passes posture at 9am and then becomes non-compliant at 2pm (Intune marks it non-compliant due to missing patch) is blocked from new connections at 2pm.
How do I plan a phased VPN-to-ZTNA migration without disrupting existing access?
Plan a phased VPN-to-ZTNA migration by migrating applications to ZTNA one category at a time, running ZTNA alongside VPN during the transition period, and progressively restricting VPN access as applications move to ZTNA. Phase 1 (0-30 days): migrate internal web applications (internal wikis, HR systems, development tools) to ZTNA. These applications are the lowest-risk migration because they use HTTPS and are naturally compatible with an identity-aware proxy — no application changes are required. Phase 2 (30-90 days): migrate developer tools (SSH access to servers, database access, code repositories) to ZTNA using SSH and TCP application types in the ZTNA platform. Phase 3 (90-180 days): migrate remaining applications including legacy systems that may require special handling. During all phases, keep VPN available but progressively restrict VPN network access as applications move to ZTNA — after Phase 1, remove web application server subnets from VPN routing since those applications are now accessible via ZTNA. By Phase 3 completion, VPN access has been narrowed to only the remaining applications not yet migrated, at which point the total VPN user count and network access surface is a small fraction of the original. The final VPN deprecation date occurs when all applications are in ZTNA and VPN is no longer needed.
How do I create ZTNA access policies that align with organizational roles?
Create ZTNA access policies by mapping application access to identity provider groups that reflect organizational roles, so that group membership in the IdP drives ZTNA application access without requiring per-user policy management. In the identity provider (Okta, Azure AD), create groups that reflect job function and access need: engineering-team, devops-team, finance-team, hr-team, security-team. Assign each employee to their appropriate functional groups during onboarding. In the ZTNA platform, create Access Policies for each application that reference these IdP groups: the production-kubernetes-dashboard application requires membership in devops-team AND device posture compliance; the internal-wiki application requires membership in any employee group. When a new engineer joins, adding them to engineering-team and devops-team in the IdP automatically grants ZTNA access to all applications those groups are authorized for — no ZTNA policy update required. When an engineer transfers to the finance team, removing them from engineering-team and devops-team and adding them to finance-team revokes their ZTNA access to engineering applications and grants access to finance applications within the time it takes the IdP group change to propagate (typically under 5 minutes with ZTNA's continuous policy evaluation). This contrasts with VPN offboarding where removing access requires updating firewall rules or VPN ACLs that may not be consistently applied.
How do I handle legacy applications that do not support modern authentication in a ZTNA deployment?
Handle legacy applications that do not support modern authentication (SAML, OAuth, OIDC) in a ZTNA deployment by using the ZTNA platform's TCP tunneling or network connector capabilities to wrap legacy application protocols in identity-verified tunnels without modifying the applications. For legacy SSH access (a common ZTNA migration challenge): Cloudflare Access for Infrastructure provides SSH proxying where users authenticate to the ZTNA platform using their IdP credentials, and Cloudflare proxies the SSH connection to the server using short-lived SSH certificates signed by Cloudflare's CA. The SSH server trusts Cloudflare's CA (configured in sshd_config with TrustedUserCAKeys pointing to Cloudflare's public key) and accepts certificates from any user authenticated through Cloudflare Access. The user's SSH client uses the cloudflared SSH proxy: Host internal-server, ProxyCommand cloudflared access ssh --hostname internal-server.example.com which routes the SSH connection through the ZTNA identity verification before reaching the server. For legacy database connections, TCP tunneling in ZTNA allows wrapping database protocol connections in an identity-verified ZTNA session: users run cloudflared access tcp --hostname db.example.com --url localhost:5432 to create a local port that proxies through ZTNA to the database server after identity verification.
How do I measure the security improvement from ZTNA deployment compared to the previous VPN architecture?
Measure ZTNA security improvement using four metrics that directly compare the access control posture before and after migration: lateral movement blast radius reduction, access policy granularity, access event audit coverage, and time-to-revoke for departed employees. Lateral movement blast radius: before ZTNA, calculate the number of systems reachable from the VPN subnet for an average user (list all network ACL rules allowing traffic from the VPN CIDR range). After ZTNA migration, the equivalent metric is the number of ZTNA applications authorized for an average user — typically 5-15 specific applications versus hundreds of servers on VPN. Access policy granularity: count the number of distinct access policies in VPN (typically firewall rules measured in tens or hundreds) versus ZTNA (per-application policies with device posture and IdP group conditions). Access event audit coverage: VPN typically provides connection-level logs (user connected to VPN from IP at time) while ZTNA provides per-request logs (user accessed specific application URL at time from device with specific compliance status). Time-to-revoke: test by removing a test user from the IdP and measuring how long before ZTNA denies access. ZTNA's IdP integration typically revokes access within 5 minutes of account deprovisioning. Document these four metrics at the start of the ZTNA migration and re-measure at 30, 90, and 180 days post-migration to demonstrate quantifiable security improvement to leadership.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.