Agentless vs Agent-Based ZTNA

Agent-based ZTNA supports all protocols (TCP/UDP), provides continuous device posture checks, and handles thick-client apps. Agentless ZTNA works through the browser for web apps only — ideal for contractors and BYOD. Most organizations need both: agent for managed devices, agentless for third parties. Deploy agent-based first, add agentless for contractor access.

Agent-based ZTNA deploys a software agent on the endpoint that authenticates the user, collects device posture telemetry, and establishes encrypted micro-tunnels to specific applications through a cloud broker. Agentless (clientless) ZTNA provides browser-based access to web applications through a reverse proxy without requiring any software installation on the endpoint. Most enterprise ZTNA deployments use both models simultaneously: agent-based for managed corporate devices where you need full protocol support and deep posture checks, and agentless for BYOD devices, third-party contractors, and scenarios where endpoint software installation is impractical or politically impossible. The decision is not which model to choose — it is which applications and user populations get which model.

Feature comparison

When to use agent-based ZTNA

Agent-based ZTNA is the right choice for managed corporate devices where you control the endpoint and can enforce software installation through MDM or endpoint management platforms. The agent provides capabilities that are impossible without endpoint presence: deep device posture verification (is the EDR agent running? is disk encryption enabled? is the OS patched?), full protocol support for non-HTTP applications (SSH to servers, RDP to virtual desktops, proprietary thick-client protocols), continuous trust verification that can terminate a session in real time if posture degrades, and DLP controls that extend to the endpoint's clipboard and file system.

For your employee population accessing business-critical applications on company-issued devices, agent-based ZTNA should be the default. The installation overhead is a one-time cost that you pay during deployment, and the security benefits compound every day after. The agent also enables always-on access — users do not need to manually connect or navigate to a portal. Applications configured in the ZTNA policy are simply accessible, exactly like they would be on the corporate network, but with per-application isolation and continuous posture enforcement.

The critical caveat is agent compatibility. Every ZTNA agent is effectively a network driver that modifies routing tables, DNS resolution, and potentially proxy settings. Conflicts with VPN clients, other security agents (EDR, DLP, endpoint firewall), and enterprise software that also hooks into the network stack are common. Test thoroughly across your standard operating system images before broad deployment. Prioritize vendors whose agents coexist well with your existing endpoint security stack — ask for explicit compatibility matrices.

When to use agentless ZTNA

Agentless ZTNA is essential for three scenarios. First, BYOD: employees using personal laptops, tablets, or phones to access corporate web applications. They will not install corporate software on personal devices, and you should not ask them to — the privacy and liability implications of corporate agents on personal devices create legal and HR complications. Agentless ZTNA through a browser provides authenticated, policy-controlled access without touching the personal device.

Second, third-party contractors and partners. External consultants, auditors, temporary workers, and partner organizations need access to specific applications for limited durations. Deploying endpoint agents on devices you do not own or manage is operationally expensive and creates offboarding headaches. Agentless ZTNA lets you provision browser-based access tied to a time-limited identity, with no endpoint footprint to clean up when the engagement ends.

Third, break-glass access. When a managed device fails and the user needs to access a critical application from an unmanaged device — a hotel business center computer, a borrowed laptop, a personal tablet — agentless ZTNA provides emergency access with reduced trust. You can enforce additional authentication factors, restrict to read-only access, disable downloads and clipboard, and watermark the session to deter data capture. This is not the primary access model but it is an essential fallback.

The hybrid model in practice

Every mature ZTNA deployment uses both models. The architecture typically looks like this: managed corporate devices run the ZTNA agent with full protocol support, deep posture checks, and access to all authorized applications including thick-client and SSH/RDP resources. Unmanaged BYOD devices and contractor devices use agentless browser-based access restricted to web applications only, with reduced trust levels (no access to sensitive administrative interfaces, no file download for certain data classifications, watermarked sessions). The same ZTNA policy engine handles both models with different trust tiers.

Configure your identity provider to signal device management status to the ZTNA broker. Microsoft Entra ID (Entra ID) and Okta both support conditional access policies that check whether the device is managed (joined to MDM, Intune-compliant, etc.). Use this signal to automatically route managed devices through agent-based ZTNA and unmanaged devices through agentless ZTNA, with different application access scopes and security controls for each. This eliminates manual routing decisions and ensures consistent policy enforcement.

Security implications of each model

Agent-based ZTNA is materially more secure because posture verification is the foundation of zero trust. Without an agent, you cannot verify that the device has an active EDR agent, enabled disk encryption, current OS patches, or a trusted certificate. You are granting application access based on identity alone, which is better than VPN but does not fully implement zero trust principles. Organizations in regulated industries (healthcare, financial services, government) should mandate agent-based ZTNA for any access to systems containing regulated data, using agentless only for non-sensitive applications.

Vendor implementation differences

Vendor implementations of agentless ZTNA vary significantly. Zscaler Private Access offers clientless access through ZPA's browser-based portal with application isolation. Cisco provides clientless ZTNA through Secure Access with browser-rendered SSH and RDP sessions in addition to standard web applications. Palo Alto Prisma Access supports clientless ZTNA for web applications through the GlobalProtect portal. Netskope offers browser-based access through the Netskope Private Access portal. The key differentiator to evaluate is protocol support: some vendors only support HTTP/S in clientless mode, while others render SSH and RDP sessions in the browser, which dramatically expands the use cases agentless ZTNA can cover.

On the agent side, evaluate client stability across your OS mix. If your fleet is 60% Windows and 40% macOS, test the ZTNA agent extensively on both platforms. Some agents have known stability issues on macOS, particularly around handling macOS networking stack changes after OS upgrades. Check vendor release notes for your specific OS versions and ask for customer references with a similar OS mix to validate real-world stability.

Sources & further reading

• NIST SP 800-207, "Zero Trust Architecture" — nist.gov/publications/zero-trust-architecture
• CISA, "Zero Trust Maturity Model" — cisa.gov/zero-trust-maturity-model
• Gartner, "Market Guide for Zero Trust Network AccessZero Trust Network Access" — gartner.com/reviews/market/zero-trust-network-access
• Palo Alto Networks, "ZTNA 2.0: Agent-Based vs Clientless" — paloaltonetworks.com/cyberpedia/what-is-ztna-2-0
• Cloudflare, "What is ZTNA?" — cloudflare.com/learning/access-management/what-is-ztna

Related on sase.cloud

One email per publish. Unsubscribe anytime.