How to Implement Zero Trust Network Access (ZTNA) in an Enterprise Environment
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.
Traditional VPN grants broad network access after a single authentication event: once connected, a user (or attacker with stolen credentials) can reach any resource on the internal network segment. Zero Trust Network Access replaces this model with application-level access grants based on continuous verification of who the user is, what device they're using, whether that device is healthy, and the contextual risk of the access request. This guide covers the implementation mechanics for deploying ZTNA in a hybrid enterprise environment.
Design the Zero Trust Architecture
ZTNA architecture has three core components: (1) Identity Provider (IdP): the authoritative source of user identity, typically Entra ID (formerly Azure AD), Okta, or Ping Identity; handles MFA and provides identity signals to the ZTNA control plane; (2) ZTNA Policy Engine: evaluates access requests against policies combining identity, device posture, application sensitivity, and contextual risk; Zscaler Private Access, Cloudflare Access, and Palo Alto Prisma Access are the leading commercial implementations; (3) Application Connectors: lightweight agents deployed inside the private network (on-premises or cloud) that proxy application traffic through the ZTNA service without requiring inbound firewall rules. The data flow: user request > ZTNA client on endpoint > ZTNA cloud service (identity and posture check) > policy evaluation > connector in private network > application. The application never receives a direct connection from the internet: all traffic routes through the ZTNA service, which enforces access control inline. Start with a pilot group (50-100 users) accessing a non-critical internal application before migrating production traffic.
Configure Identity Integration
ZTNA relies on identity assertions from your IdP. Configure SAML or OIDC federation between your IdP and the ZTNA platform. For Zscaler Private Access with Entra ID: Entra ID > Enterprise Applications > Add Zscaler Private Access > Configure SAML. Map claims: UPN as NameID, department and jobTitle attributes for policy group membership. For Cloudflare Access with Okta: Cloudflare Zero Trust > Settings > Authentication > Add Okta as OIDC provider, configure client_id and client_secret from Okta's OAuth 2.0 application. Create access groups in the ZTNA platform that mirror your IdP groups: IT-Admins, Finance-Users, Engineering. Policy example in Cloudflare Access:
Application: Internal HR System
Policy: Allow
Include: Group = Finance-Users
Require: Identity Provider MFA = Enforced
Require: Device Posture = Intune-Compliant
Action: Allow for 8 hours
Test identity federation before adding device posture requirements: verify group claims pass correctly and users can authenticate before layering posture checks.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Implement Device Trust and Posture Checks
Device posture evaluation is what differentiates ZTNA from a simple identity-based firewall. Integrate the ZTNA platform with your MDM/UEM (Intune, Jamf, Workspace ONE) to evaluate device compliance at access time. Posture checks to configure: (1) OS version: deny access from endpoints running OS versions with known critical vulnerabilities (e.g., Windows below a specific patch level); (2) EDR presence: verify the Defender, CrowdStrike, or SentinelOne agent is running and reporting healthy; (3) Disk encryption: verify BitLocker (Windows) or FileVault (macOS) is enabled; (4) Certificate-based device trust: issue device certificates from your internal CA and require the certificate be present and valid at access time; (5) Screen lock: verify screen lock is configured with a timeout under 15 minutes. In Zscaler Private Access, configure posture profiles under Policy > Device Posture Profiles. Map posture profile results to access policies: users on compliant devices get full application access; users on non-compliant devices get restricted read-only access or are denied entirely depending on application sensitivity.
Deploy Application Connectors
Application connectors are the ZTNA component that bridges the ZTNA cloud service to your internal applications. Deploy connectors close to the applications they protect: in the same VPC, data center segment, or virtual network. Zscaler App Connector deployment on Linux:
# Download connector from Zscaler portal
wget https://connector.zscaler.net/packages/linux/latest/ZscalerAppConnector.tar.gz
tar xzf ZscalerAppConnector.tar.gz
./install.sh
# Provision with API key from ZPA admin portal
./zpa-connector register --api-key <key> --connector-name prod-connector-01
Deploy at least two connectors per application segment for high availability: connectors load-balance automatically. The connector establishes an outbound TLS connection to the ZTNA cloud service (no inbound rules required) and advertises which applications it can reach. In the ZTNA admin portal, create Application Segments defining which internal IP ranges and ports the connector exposes: 10.0.10.0/24:443 for the web application tier. Test connectivity: from a ZTNA-enrolled client device, attempt to reach the application URL and verify the ZTNA client intercepts the request, validates identity and posture, and proxies through the connector.
Migrate Applications from VPN
Migrate applications from VPN to ZTNA in order of risk and business impact. Start with: (1) SaaS applications that already have identity-based access: add Cloudflare Access or Zscaler Internet Access in front of these to add device posture checks without changing the application; (2) Internal web applications accessible via a browser: these work transparently with ZTNA browser-based access; (3) Custom internal applications requiring thick client access: these require the ZTNA client installed on endpoints and may need application-specific connector configuration. Create a migration tracking spreadsheet: application name, current access method (VPN subnet, direct access), ZTNA application segment name, connector deployed, pilot user group, production rollout date. For each migrated application: block VPN access to that application's IP range in your firewall policy to prevent VPN bypass. Do not allow users to simultaneously have VPN and ZTNA access to the same resource: split tunneling in VPN can become a bypass path.
Configure Micro-Segmentation Policies
ZTNA micro-segmentation limits the blast radius of a compromised credential by granting access only to specific applications rather than network subnets. Define application access policies with least privilege: Finance users can reach finance-app.internal:443 only, not the entire 10.0.0.0/8 network. Engineering can reach Git, CI/CD, and dev environment IPs but not HR systems or finance applications. IT Admins with privileged access require step-up MFA and a separate privileged access policy. Example policy hierarchy in Palo Alto Prisma Access:
Highly Sensitive Applications (HR, Finance, Legal):
- Require: Privileged Identity + Compliant Device + Phishing-Resistant MFA
- Session duration: 4 hours, re-authenticate after 2 hours of inactivity
Internal Business Applications:
- Require: Standard Identity + Compliant Device + TOTP MFA
- Session duration: 8 hours
Development Tools:
- Require: Standard Identity + MDM-Enrolled Device
- Session duration: 12 hours
Review and prune access policies quarterly: application access creep is a common problem where users accumulate access to applications they no longer need.
Monitor and Alert on ZTNA Events
ZTNA platforms generate rich access logs that enable detection of credential compromise and policy violations. Key events to alert on: (1) Access denied due to posture failure: user has valid credentials but device is non-compliant; investigate whether the device has been compromised or whether the user is attempting to access from a personal device; (2) Access from unexpected geographic location: same user authenticating from two countries within 24 hours; (3) High-volume access denials: one account generating dozens of denials in an hour may indicate credential stuffing or an automated tool; (4) Privileged application access outside business hours: HR or finance system access at 2:00 AM; (5) First-time access to sensitive applications. Forward ZTNA logs to your SIEM via syslog, API integration, or native SIEM connector. Zscaler provides native connectors for Splunk, Microsoft Sentinel, and IBM QRadar. Cloudflare Access logs are available via Logpush to S3 or your SIEM. Build a weekly ZTNA posture review: how many devices are accessing resources with non-compliant posture (allowed by exception), what percentage of access requests are being denied and why.
The bottom line
ZTNA implementation requires four components working together: IdP integration for identity assertion, device posture evaluation via MDM integration, application connectors inside the private network, and micro-segmentation policies that grant per-application access rather than network access. Start with a pilot group accessing a non-critical application, validate identity federation and posture checks before migrating production traffic, and block VPN access to each migrated application to prevent bypass. Monitor ZTNA access logs for posture failures, impossible travel, and after-hours sensitive application access.
Frequently asked questions
What is the difference between ZTNA and VPN?
VPN grants broad network-level access after a single authentication event: once connected via VPN, a user can reach any resource on the connected subnet, enabling lateral movement if credentials are compromised. ZTNA grants access to specific applications based on continuous verification of user identity, device health, and contextual risk signals. A compromised credential in ZTNA only provides access to the specific applications that credential is authorized for, not the full internal network. ZTNA also evaluates device posture at each access request, blocking access from non-compliant devices even with valid credentials.
How do application connectors work in ZTNA?
ZTNA application connectors are lightweight agents deployed inside your private network that establish outbound TLS connections to the ZTNA cloud service. When an authorized user accesses an internal application, the ZTNA service routes the traffic through the connector to the application. The connector eliminates the need for inbound firewall rules: the application is never directly internet-accessible. Deploy at least two connectors per application segment for high availability, placing them in the same network segment as the applications they protect.
What is the difference between agent-based and agentless ZTNA?
Agent-based ZTNA installs a client application on the user's device that handles authentication, device posture checking, and traffic routing to internal applications. The agent enables continuous device health verification (OS patch level, EDR running, disk encryption status) at every access request. Agentless ZTNA provides access via a web browser to web applications only, without a device agent — useful for contractor or BYOD access where installing agents is not possible, but device posture cannot be verified. Most enterprise ZTNA deployments use agent-based access for employees (full device posture) and agentless browser-based access for third-party vendors (web app access without requiring agent installation on unmanaged devices).
Which ZTNA solutions should enterprises evaluate?
Leading enterprise ZTNA solutions by deployment model: Cloudflare Access (cloud-native, no hardware, connector-based, integrates with Cloudflare WAF and DDoS protection); Zscaler Private Access (ZPA, cloud-based, strong integration with Zscaler Internet Access for unified SASE); Palo Alto Prisma Access (SASE platform combining ZTNA with cloud-based firewall); Microsoft Entra Private Access (formerly Azure AD Application Proxy successor, tight Entra integration, good for Microsoft-centric environments); and Netskope Private Access (cloud-native, strong DLP integration). Key evaluation criteria: latency for your user locations (connector placement matters), integration with your existing IdP, device posture check capabilities, and whether you need a unified SASE platform or standalone ZTNA.
How do I migrate from VPN to ZTNA without disrupting users?
VPN to ZTNA migration approach: (1) Inventory all VPN use cases — remote desktop to servers, web application access, file share access, RDP to developer workstations, and third-party vendor access. Each use case has a different ZTNA configuration. (2) Start with web application access (the easiest ZTNA use case): proxy internal web apps through ZTNA while VPN remains available. (3) Expand to SSH/RDP access via ZTNA browser rendering or native client tunneling. (4) Migrate file share access last (most operationally complex). (5) Run VPN and ZTNA in parallel for 30-60 days while users build familiarity. Avoid a hard cutover: let users move to ZTNA organically, then set a VPN decommission date with advance notice. The most common migration failure: moving before resolving all non-web application use cases that users depend on daily.
How do I handle ZTNA connector high availability and failover without creating security gaps?
Deploy a minimum of two application connectors per application segment in separate availability zones or physical locations: ZTNA connectors load-balance across active instances and failover automatically when one becomes unreachable, with no configuration change required on the client side. Monitor connector health via your ZTNA platform's admin portal and create alerts when connector count for any segment drops below two -- a single-connector segment has no redundancy and a connector failure creates an outage. For on-premises connector deployments, use separate physical hosts or hypervisor hosts rather than multiple VMs on the same physical server, which shares the same failure domain. Test failover quarterly by deliberately stopping one connector and verifying that application access continues without user interruption -- document the test results to confirm your HA configuration actually works before a real failure occurs. Connector version updates can cause brief outages if applied to all connectors simultaneously: stagger updates by applying to one connector, verifying application access, then updating the remaining connectors. Use your ZTNA platform's connector health API to integrate status into your existing infrastructure monitoring system rather than relying solely on the ZTNA portal for visibility.
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.